Topic: The same (smart) AutoCAD .Net Extension template for any AutoCAD version

[Andrey Bushman]

This template was created for solving such tasks:

1 The template provides some base functional and structure (as any template too).

2. Possibility of switching between target AutoCAD versions for debugging and code writting. When target AutoCAD switching of is occured then all references and project settings have to be updated automatically.

3. Simple compilation the same project through "one click of a mouse" for all necessary AutoCAD versions.

4. Entry point creating.

5. Possibility of fast switching between computers for debugging: localhost or any remote machine. For example, code can be tested and debugged on the machines working under control of WinXPx86, Win7x64, Win7x86 for to be convinced that it works normally for all necessary OS.

6. Division of settings for three groups: the general settings (affect all projects); the general settings for AutoCAD projects (affect projects of all AutoCAD extensions); and individual settings (affect only the specific project). The settings which aren't the individual are applied immediately at once to all existing and again created projects. Such approach allows to make quickly and easily changes at once to all necessary projects.

7. Portability of all projects, based on this template, to other computers. On one computers distribution kits of ObjectARX SDK can be unpacked directly on the disk "C:\" or "D:\" (the most disgusting variants), on others unpacking is carried out not in the root catalog, but in the subdirectory which is specially taken away for this purpose, for example "%HOMEDRIVE%\SDK" (it is already much better). I prefer to unpack it in the catalog of "%SDK%\<Company-Name>\<Product-Name>\<SDK-Version>". The %SDK% Windows-variable created by me always indicates the catalog which is the general for any SDK. As I am not limited to use only of ObjectARX SDK, such approach seems to me the most reasonable. We will return to portability... In this case I mean lack of need of reconnection of the references of the project when on the computer where the project was copied, the location of ObjectARX SDK differs from location on the original computer. If one project is transferred - isn't a problem to reconnect its references , but also it doesn't give pleasure, especially if to consider that then the project can be necessary to copy to the original computer back and again to reconnect all references. However, when a quantity of copied projects is big, such reconnection of references already becomes very inconvenient.


Video with english text comments is here.

I still not learn the variant of decission the same theme by CADbloke, but now I can to do it (and I will learn it). I will be glad for the useful remarks and wishes in relation to the idea designated by me in the video. If someone except me and CADbloke is interested in similar questions...

P.S. I apologize for my horrible English.

[Andrey Bushman]

Oh... I forgot to remove sound from video, as I see. Therefore I delete video from youtube now. Tomorrow I will do it and publish video again. Also I will show some additional things. Now I am at home.

[Andrey Bushman]

I rewrote video and added the English comments into it. I updated the link in my first message of this theme. Additional I locate the same (as in video) comments here (it may be interesting for anybody also).

1. Run Visual Studio 2013.

2. Create a new project based on AutoCAD .Net Extension template and set the "MySomeExtensions" name for this.

3. Look, the "MySomeExtensions.csproj.user" file is not exists still. It is necessary to create it and change its content.

3.1. Go to "Debug" tab in the project settings and write anything into the "Command line arguments" field.

3.2. Change a focus. For example, click on the "Working directory" field.

3.3. Now the "MySomeExtensions.csproj.user" file was created as you can see.

3.4. Open the "%ProgramData%\Bushman\config\developing\Autodesk\AutoCAD\debug\readme.txt" file in a text editor and copy to clipboard the XML code, which are located at the end of the file.

3.5. Close the "%ProgramData%\Bushman\config\developing\Autodesk\AutoCAD\debug\readme.txt" file.

3.6. Open the "MySomeExtensions.csproj.user" in a text editor.

3.7. Select all content of the "MySomeExtensions.csproj.user" file and remove it.

3.8. Past the content of the clipboard in the "MySomeExtensions.csproj.user" file. Save it and close.

4. Restart Visual Studio and open the "MySomeExtensions" project again. It is necessary for applying changes what we did for the "MySomeExtensions.csproj.user" file.

5. Go to "Debug" tab in the project settings. You see now its settings are filled. Now the "Start external program" option is selected and has the "C:\Program Files\Autodesk\AutoCAD 2009\acad.exe" value. I.e. as you can guess, now the project is adjusted on compilation and debugging for AutoCAD 2009. Also the "Use remote machine" options is checked and has the "win7x64ac2" as value (we will "speak" about it later).

6. Look ObjectARX SDK reference files location. Also pay attention the Interop assemblies is linked too. The referenced files located in the "ObjectARX 2009\inc-x64" subdirectory.

7. Open the "Application" tab in the project properties. Pay attension on the "Assembly name" and "Target framework" values: "MySomeExtensions.R17.2x64" and .Net Framework 3.5.

8. Open the "Build" tab in the project properties. Look the "Conditional compilation symbols":
AUTOCAD;AUTOCAD_2009;PLATFORM_x64;NET35;AUTOCAD_NEWER_THAN_2008

9. Look the "Target platform" value, it is the "x64".

10. Look at the "Output path" value, it has the
"\\win7x64ac2\public\Debug\extensions\acad-extensions\MySomeExtensions\bin\".

11. Close the project properties window.

12. Open the Commands.cs file.

13. Replace the "// Write your code here..." code row on the "ed.WriteMessage("Hello, World!");" value (row 75).

14. Replace the [Rt.CommandMethod(cmdGroup, "test", "LocalizedNameId",
      Rt.CommandFlags.Modal, contextMenuExtensionType, helpFileName,
      helpFileTopic)] on the [Rt.CommandMethod("test", Rt.CommandFlags.Modal)] (row 64).

15. Save the changes.

16. Now we need to debug our "super usefull" program. Set the breackpoint in the "tr.Commit();" line (row 74).

17. We will use the remote debugging in this sample. My remote computer is the virtual machine, which is working on the server. We will connect to it through the RDP.

18. When I connected to the remote machine, I run the Remote Debugging Monitor 2013 at first. Now we can do the remote debugging.

19. Clear the output directory. It is locating on the remote machine ("C:\public" directory).

19.1. In the MS Visual Studio run the "Rebuild Solution" command.

20. Press F5 key.

21. On the remote machine was started AutoCAD 2009, as you can see.

22. In the AutoCAD 2009 run the _NETLOAD command and select the "C:\public\Debug\extensions\acad-extensions\MySomeExtensions\bin\MySomeExtensions.R17.2x64.dll" file.

23. In AutoCAD 2009 console you can see the text "The "C:\public\Debug\extensions\acad-extensions\MySomeExtensions\bin\MySomeExtensions.R17.2x64.dll" assembly successfully loaded." now.

24. Run the TEST command in the AutoCAD console. Breackpoint will work now (you can see it in the IDE).

25. Press F5 now and look the AutoCAD console output: "Hello, World!".

26. Ok. Now close AutoCAD 2009.

27. But what if we want to build our project as AnyCPU, instead of x64? Pay attension: Interop assemblies are linked to our project still.

28. WARNING! Remember: don't change the settings of your project (the Application, Build and Debug tabs) through the Visual Studio GUI manually! Their property values are EVALUATED (it evaluate on base target AutoCAD and platform version). If you will change their value in the GUI - it will be static now. Later, in this article, I will discribe how to do it right. Also don't pay attention on the values of current "Solution Platform" in the Visual Studio.

28.1. Open the "MySomeExtensions.csproj" file in the text editor.

29. Set the 2009 value into the CAD_Year_Platform property (instead of old 2009x64 value).

30. Save the changes and close text editor.

31. In the Visual Studio you will see the "File modification detected" window. Press the "Reload all" button.

32. Look references again. You see, the Interop references is not linked now.

33. Also the "Conditional compilation symbols" has the PLATFORM_AnyCPU instead of PLATFORM_x64 now.

34. Also the "Assembly name" is the "MySomeExtensions.R17.2" now instead of "MySomeExtensions.R17.2x64".

34.1. But Object ARX SDK 2009 had not still the managed wrappers in the "inc" subdirectory. Therefore inc-x64 are used still for AutoCAD 2009.

35. Ok, but we want to build this project for the several AutoCAD versions. How to do it?

36. It is wery simple. At first, remove the content of the "C:\public" directory of our remote machine (for purity of experiment).

37. In the Solution Explored do the click of the mouse right button on the "_debug-build-all.bat" file and select the "Open Command Prompt" context menu item. Cmd.exe window will be opened.

38. In the Cmd.exe window write the _d and press the TAB key. The "_debug-build-all.bat" will be written. Press ENTER key. That's all. MSBuild builds your project for all neccessary AutoCAD versions!

39. On the remote machine, in the "C:\public\Debug\extensions\acad-extensions\MySomeExtensions\bin" directory now exist files: MySomeExtensions.dll, MySomeExtensions.R17.2x64.dll, MySomeExtensions.R17.2x86.dll, MySomeExtensions.R19.0.dll, MySomeExtensions.R20.0.dll.

40. You can see, each of DLL file name starts with the "MySomeExtensions" prefix. Sufixes point to the target AutoCAD and platform: R17.2 - is the core version of AutoCAD 2009, R19.0 - AutoCAD 2013, R19.0 - AutoCAD 2015. The x64 and x86 is the target platforms. If the DLL has not the x64 or x86 sufix - its target platform is AnyCPU.

41. But pay attention on the MySomeExtensions.dll file. It hasn't any sufixes. What is it? Into what AutoCAD it can be loaded? The answer is simple: the MySomeExtensions.dll file can be loaded into any AutoCAD, because it is an "entry point". When the MySomeExtensions.dll is loaded into AutoCAD, it finds the most suitable version of your assembly (which name starts with the same name, has the AutoCAD core suffix and (optional) target platform). For example: when the MySomeExtensions.dll will be loaded into the AutoCAD 2009, 2010, 2011 or 2012, then it load the MySomeExtensions.R17.2x64.dll also (because the our platform is x64 and we did't create the MySomeExtensions.R17.2.dll assembly). Other case, when the MySomeExtensions.dll will be loaded into the AutoCAD 2013, 2014, then it load the MySomeExtensions.R19.0.dll also. When the MySomeExtensions.dll will be loaded into the AutoCAD 2015, then it load the MySomeExtensions.R20.0.dll also. Existing of "entry point" does our .net-extension more extensible. For example, when will be released AutoCAD 2016, it is enough to add the 40. You can see, each of DLL file name starts with the "MySomeExtensions" prefix. Sufixes point to the target AutoCAD and platform: R17.2 - is the core version of AutoCAD 2009, R19.0 - AutoCAD 2013, R19.0 - AutoCAD 2015. The x64 and x86 is the target platforms. If the DLL has not the x64 or x86 sufix - its target platform is AnyCPU.

41. But pay attention on the MySomeExtensions.dll file. It hasn't any sufixes. What is it? Into what AutoCAD it can be loaded? The answer is simple: the MySomeExtensions.dll file can be loaded into any AutoCAD, because it is an "entry point". When the MySomeExtensions.dll is loaded into AutoCAD, it finds the most suitable version of your assembly (which name starts with the same name, has the AutoCAD core suffix and (optional) target platform). For example: when the MySomeExtensions.dll will be loaded into the AutoCAD 2009, 2010, 2011 or 2012, then it load the MySomeExtensions.R17.2x64.dll also (because the our platform is x64 and we did't create the MySomeExtensions.R17.2.dll assembly). Other case, when the MySomeExtensions.dll will be loaded into the AutoCAD 2013, 2014, then it load the MySomeExtensions.R19.0.dll also. When the MySomeExtensions.dll will be loaded into the AutoCAD 2015, then it load the MySomeExtensions.R20.0.dll also. Existing of "entry point" does our .net-extension more extensible. For example, when will be released AutoCAD 2016, it is enough to add the MySomeExtensions.R20.1.dll into your extension directory. into your extension directory (if AutoCAD 2016 wil can not load the MySomeExtensions.R20.0.dll).

42. Ok, come back to our project settings... What is the _debug-build-all.bat file? It is a BAT-script which runs the MSBuild with the necessary options for the batch building. The result assemblies are builded with the DEBUG configuration. Similar, the _release-build-all.bat builds all necessary assemblies with the RELEASE configuration.
WARNING! if you will rename your csproj-file later, then you must rename it in the _debug-build-all.bat and _release-build-all.bat files too.

43. But how can I define the target AutoCAD versions for the batch building? It is simple too: Open the "MySomeExtensions.csproj" file and find the "BuildFor" XML element. By default its value is "EntryPoint;2009x86;2009x64;2013;2015". I think you understand what does it mean. You can change it as you need and save the changes.

44. What if I want debug for other AutoCAD version, not for AutoCAD 2009? Open the "MySomeExtensions.csproj" file and find the "CAD_Year_Platform" XML element. For example, write the 2010x64, if you want to debug for the AutoCAD 2013x64, or set the 2015, if you want to debug for AutoCAD 2015 AnyCPU. Don't forget to save your changes. When you will do it, all references and project settings will updated immediately (as you saw already earlier).

45. The projects based on this template are portable (between developers). What does it mean? One developer can locate own ObjectARX SDK directories in the "C:\" directory directly. Other - in the "D:\SDK\Autodesk\AutoCAD" (my case), or other location. You can copy your project directory into other computer and it is not necessary to update all its references. How does it work? Ok, look it now.

46. I keep the ObjectARX SDK in the "D:\SDK\Autodesk\AutoCAD" directory. Close Visual Studio and rename this path as "D:\SDK-000\Autodesk\AutoCAD". Open our project in the IDE again. We get the resolved references. Ok, close IDE. Open the "%ProgramData%\Bushman\config\developing\common.props" file and change the value of the "SDKLocation" XML element: the "D:\SDK-000" instead of "D:\SDK". Save the changes. WARNING: The specified way shouldn't end with by the "\" symbol. Open our project again - now all is fine!

47. Ok, but what if you use more than one remote machine for debugging, or use local machine only? This is not a problem! Open the "MySomeExtensions.csproj" file and find the "MachineName" XML element. Write the localhost if you use the local machine. If you want to debug for other remote machine - write its name here. Save your changes. How does it work? Open the "%ProgramData%\Bushman\config\developing\Autodesk\AutoCAD\debug" directory. By default you will see three files: the readme.txt, acad-localhost-debug.props and acad-win7x64ac2-debug.props. This directory contains the debug settings for each machine (local or remote).
For each machine the settings are stored in own file with name acad-MachineName-debug.props, where MachineName is "localhost" or remote machine name.

48. Ok, but what must I do, when the new AutoCAD released by Autodesk? No problem:

48.1. Open the "%ProgramData%\Bushman\config\developing\Autodesk\AutoCAD\acads-list.props" file.

48.2. Add the "When" block at the end for new AutoCAD version by analogy with the previous XML elements. For example, for AutoCAD 2016 you must to add this:

Code: [Select]

<!-- AutoCAD 2016 -->
<When Condition= "'$(CAD_Year) == 2016'">
  <PropertyGroup>
    <CADCoreMajor>20</CADCoreMajor>
    <CADCoreMinor>1</CADCoreMinor>
    <!-- Can be used the .NET 4.5, 4.5.1. -->
    <TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
  </PropertyGroup>
</When>
48.3. Save the changes and close the file.

48.4. Open the "%ProgramData%\Bushman\config\developing\Autodesk\AutoCAD\acad-common.props" file.

48.5. Find the "<NewerThanPrefix>AUTOCAD_NEWER_THAN_</NewerThanPrefix>" string. Under this line you will see a set of "DefineConstants" XML elements.

48.6. Add the "DefineConstants" block at the end for new AutoCAD version by analogy with the previous XML elements. For example, for AutoCAD 2016 you must to add this:

Code: [Select]

<DefineConstants Condition= "'$(CAD_Year)' &gt; '2016'">$(DefineConstants);$(NewerThanPrefix)2016</DefineConstants>
48.7. Save the changes and close the file.

48.8. Add the new ObjectARX SDK into your SDK location. That's all.

49. How can I change default settings of template (target AutoCAD version for debugging, target AutoCAD versions for the batch building, etc)? Extract the AutoCAD .NET Extension.zip and edit its content as you need. Archive result back.

50. Common settings are located in the %ProgramData%\Bushman\config\developing directory, and influence on all projects (already existing and what will be created in the future) created on the basis of this template. Each of this settings file is detail commented.

51. Current template version already has necessary settings for AutoCAD 2016.

[Andrey Bushman]

I updated my first message: was added some description of  purposes of this template.

[Andrey Bushman]

As a sample of its real using, I used this template for creating an assembly for working with the proxy-entities and proxy-objects. Look attached proxy.zip file - it is a result of package building. It was created fast and without problems. proxy.dll is an Entry Point - it can be loaded into the any AutoCAD (as I wrote already). I tested it for AutoCAD 2009-2015 x64. I copied code sources into the new project from here.

[Andrey Bushman]

I have an idea about the template: it is possible to write the external application, which will located in the system tray. It will modify csproj file when and as I need. So it will not necessary to create the special templates, as I did already. This way will be more clear and safe. Now I am thinking about this...

Monologue is finished.

[CADbloke]

I have been looking into this for a while, and looking closely at Andrey's solution. I haven't written a template for my solution yet (I need to focus on my current project, not make it too easy to start new ones). Mine is less-complete than Andrey's and does not have some of his ideas like remote debugging (that is a great idea) and the Entry Point DLL (also excellent).

My approach is a little different to Andrey's (I explained it here), and perhaps a little less sane. See the attached pictures.

[Andrey Bushman]

Your screens doesn't seem for me as a "simple and convinient way". Most likely, it looks like a simple way for suicide (in any case for me). It is my "black" humour, smile. Such huge lists do frighten to me. I know, my way is not ideal too...

[CADbloke]

Yes, those lists are huge - I was being silly , that is a project I use to test every possibility for every version of every SDK I have. Most projects would only have a Debug and Release build, not the Trial and Paid versions of Debug and Release as well. The list in a real project is not that long, usually 5 - 10 each of Debug and Release. I usually leave Visual Studio set on AutoCAD 2015 Debug to write my code. If I want to test if everything builds I just use the VS menu Build -> Batch Build ... Select All...Rebuild (see picture) and they build into a different folder for each version (see other pic).

That test project with the big lists with everything in it built 126 DLLs in 45 seconds from one Visual Studio project using Batch Build. I would never do that with a real project, the most I would usually build is 5-10 each of Debug and Release.

The Trial and Paid versions set Compilation Constants so I could change the build for different versions using the same code. They are only something I would use to build a plugin for sale that if I wanted a to make a Trial version of and disable some features or change the licensing.

[Andrey Bushman]

The Trial and Paid versions set Compilation Constants so I could change the build for different versions using the same code. They are only something I would use to build a plugin for sale that if I wanted a to make a Trial version of and disable some features or change the licensing.

I think it is good idea, but bad implementation. You can have the Debug and Release configurations only - it will be enough, because you can set additional compilation constants (for Trial or Paid) through the msbuild parameters. For example, you can write in your cspoj-file something like that:

Code: [Select]

<DefineConstants>$(Constans);TRACE;DEBUG;</DefineConstants>
and to set necessary value for your Constant property, when MSBuild will be building your assembly:

Code: [Select]

MSBuild.exe /t:Rebuild /p:Configuration=Release /p:Constans=TRIAL ".\YourProject.csproj"
MSBuild.exe /t:Rebuild /p:Configuration=Release /p:Constans=PAID  ".\YourProject.csproj"

[CADbloke]

...you can set additional compilation constants (for Trial or Paid) through the msbuild parameters. For example, you can write in your cspoj-file something like that:

Code - XML: [Select]

1. <DefineConstants>$(DefineConstants);TRACE;DEBUG;</DefineConstants>

and to set necessary value for your Constant property, when MSBuild will be building your assembly:

Code: [Select]

MSBuild.exe /t:Rebuild /p:Configuration=Release /p:Constants=TRIAL ".\YourProject.csproj"
MSBuild.exe /t:Rebuild /p:Configuration=Release /p:Constants=PAID  ".\YourProject.csproj"

The MSBUILD method works and yes, it is less complicated in Visual Studio. But I will still do it my way . The advantage of putting those (Trial, Paid etc) configurations in the CSPROJ file means...

• I can see what code actually changes when I change the build in Visual Studio. This is especially helpful when I change from a >2013 AutoCAD build to a Teigha-based build, I want to see that the same code works for both builds and I can instantly see what code is broken.
• The conditional using directives at the top of the file change in Visual Studio so I can see if they are ok or not.
• Intellisense shows me what the namespaces are for the classes I am using. These can change a lot between AutoCAD and Teigha builds.
• I can step through the code in the debugger by selecting the configuration then pressing F5.
• I can also see what code is going to be compiled or skipped, especially in any Extension Methods I use to fix the differences between AutoCAD versions and between AutoCAD and Teigha applications.
• I can change the build configuration and then run my tests and see them pass for different builds.

I think that different methods will work for different people. I also think that we like to use what we are used to using 

[Andrey Bushman]

I think that different methods will work for different people. I also think that we like to use what we are used to using 

Yes, you are right, of course and your arguments are convincing too.

[Andrey Bushman]

This video shows the automatic updating of conditional compilation symbols when target AutoCAD version was changed in the csproj-file. This video is additional for the previous. I have a hope it will be a more clear answer for CADbloke's question about it (he knows what I mean).

[CADbloke]

This video shows the automatic updating of conditional compilation symbols when target AutoCAD version was changed in the csproj-file. This video is additional for the previous. I have a hope it will be a more clear answer for CADbloke's question about it (he knows what I mean).

Yes, it is clear, thank you. My question / observation was  I noticed that if I use <Choose>...<When>......</When></Choose> in the CSPROJ file then Visual Studio does not change the settings in the code for the build like it does for <PropertyGroup Condition=.... Note that this is the case for project files that are imported by the main project file, the main project file itself works ok, and it also works ok if you reload the main project.

Here are a couple of screens from the same project I posted the screens from above. I change the build configuration in the dropdown at the top in Visual Studio without reloading the project then the references change, the code that is active / inactive changes, etc.... Sometimes I have to rebuild the project to get Visual Studio to update the code if References are added/deleted (AcCoreMgd etc.) but it usually works without that.

I don't think what I have done is necessarily better than Andrey's method, his method is superior in many ways. It depends on how you like to work.

[Andrey Bushman]

Yes, it is clear, thank you. My question / observation was  I noticed that if I use <Choose>...<When>......</When></Choose> in the CSPROJ file then Visual Studio does not change the settings in the code for the build like it does for <PropertyGroup Condition=.... Note that this is the case for project files that are imported by the main project file, the main project file itself works ok, and it also works ok if you reload the main project.

Yes, I saw this problem too, when I was creating my template. In the quote I selected by red\green colors the problem\decission. So I keep in the main csproj-file such individual (for each project) settings as:

1. Target AutoCAD and its platform version for testing and debugging.
2. Target AutoCAD versions list and their platforms (optional) for the batch build.
3. Additional custom "Conditional compilation symbols".
4. etc...

Therefore I never get a problem which you pointed on your screens. Look, when you separate your settings on the common, common for all AutoCAD and individual for each AutoCAD extension project (three groups of settings) - this problem will be not existing already.

You will edit two first groups of settings very seldom. In this case it isn't difficult to restart IDE that changes became applied (or to press the "SAVE" button in your text editor which has opened your scproj-file - then IDE will reload this project settings).

Individual settings of your project will be changed often. Therefore they must to be keeped in your csproj-file instead of locating into some external XML files, attached via the 'Import' element. This way solve a problem which you pointed on your screens (and many other problems too).