I've read some responses but there are no subject headings with this.
If I want to allow 'live' debugging do I need to keep an old XP machine at hand? Seems like an annoying backwards step.
Debugging and distributing apps in two versions is annoyingly difficult to maintain.
I have a .NET2.0 version for AutoCAD 2008-2012 apps and a .NET4.0 version for AutoCAD2013-2014.
Each time I make a change to one I need to update the other, package and distribute two .dll files.
Is there anything that I don't know about that can make this process easier.
Can I have my application run as an x32 bit app on windows 7 with the 2008 x32 AcDbMgd.dll and AcMgd.dll?
Solved! Go to Solution.
>> If I want to allow 'live' debugging do I need to keep an old XP machine at hand?
Depends on what version of Visual Studio you have.
With VS releases < 2013 yes, you need a 32bit system (does not have to be XP, might be Win7x32) for "edit while debug"
With VS2013 you can "edit while debug" with 64bit too, but for that you should use AutoCAD 2015 as with AutoCAD 2014 there were some conflicts with showing text-like-objects in AutoCAD (some details to that >>>here<<<).
>> Each time I make a change to one I need to update the other
Yep, I have a project for every single release in AutoCAD, but these projects use the same source code files.
So for me I don't have to update anything in another source code file (as long as the modification is not depending on different API signatures or Invoke parameters), I just have to recompile them (and that is done automatically within our office/server).
At least it is necessary to test your software, so a project for every release of AutoCAD and the debug-settings (what ACAD.EXE has to be started) is useful for that too.
>> Can I have my application run as an x32 bit app on windows 7 with the 2008 x32 AcDbMgd.dll and AcMgd.dll?
I guess I don't understand that question. If you got AutoCAD 2008 running on Win7, why should your application, which is built for 2008, not run?
- alfred -
That clarifies the debugging problem. Maybe I will look at updating my software.
Regarding using common source code files..I currently have two project folders that contain mostly identical files.
Do I put these two project folders together into the one folder? With the two solution (.sln) files in the one master directory.
Please ignore the last question. I think you answered it when you said that you have a project for every single release. I seem to be functioning at the moment with two projects (2008-2012 and 2013-2014).
yep, for each release one project file ... but all project files (and source code files) in the same folder with names like MyTool_18_00_x32.vbproj and MyTool_18_01_x64.vbproj ...
The SLN's can be anywhere else as they are just the information about what projects to load (and the order to built them)
- alfred -
Log into access your profile, ask and answer questions, share ideas and more. Haven't signed up yet? Register