Visual Studio 2010 was released by Microsoft about a year ago. Since then, some of you have selected this IDE as your default development environment. I, personally, like Visual Studio 2010 a lot, and I am hoping to switch completely very soon. But there are a couple of issues you need to be aware if you plan to use the latest version of Microsoft’s phenomenal development environment.
Writing C++ Code
If your application is written in C++, the default Visual C++ 2010 compiler is not compatible with the API’s provided by Civil 3D 2012. This means that if you are using ‘Real DWG’, ‘Object ARX’, the ‘Custom Draw’ API, or using COM from C++, you will have to compile and link your programs using the Visual C++ 2008 compiler. You can still use Visual Studio 2010 as your development environment, but you will have to modify your project settings, so the Visual C++ 2008 compiler is used. You do this in your project properties by going to ‘Configuration Properties > General’ and setting the ‘Platform Toolset’ property to ‘v90’. Notice that Visual Studio 2010 does not install the ‘v90’ version of the toolset, so you still need Visual Studio 2008 installed on your machine.
Writing Managed/.NET Code
In the world of .NET and managed code, things are not so straight forward. When writing managed code, you can choose either version of Visual Studio, 2008 or 2010, but you also need to choose your target platform, .NET 4.0 or an earlier version.
If you plan to use Visual Studio 2008, the choice is easy because .NET 4.0 is not supported by this environment. Your applications will target earlier versions of the framework, which is totally fine, but there is a small caveat.
AutoCAD 2012 and all vertical applications, including Civil 3D 2012, install .NET Framework 4.0 during the installation process. At the same time, they configure acad.exe to use .NET 4.0 as the default run-time version of the framework. DLLs targeting earlier version can still be loaded, and they work just fine. But when you are developing your own applications, you need to debug your code, and there is a little problem. By default, Visual Studio 2008 will see that acad.exe is loading a newer version of the .NET Framework that does not know how to handle. The culprit is ‘acad.exe.config’, which contains the following line.
<supportedRuntime version="v4.0"/>
This entry in ‘acad.exe.config’ dictates .NET 4.0 should be loaded, and Visual Studio 2008 does not know how to handle that version. If you use Visual Studio 2008 as your IDE, you need to edit that line to enable debugging of your application. The change I simple; you just need to modify the version number.
<supportedRuntime version="v2.0.50727" />
Notice this change also applies if you are using Visual Studio 2010, but you target earlier versions of the framework in your projects.
The Civil 3D API team has been using both Visual Studio versions for many months now, and we have not found any issues with either one of them, nor targeting the different versions of the framework. However, there has been some reports by some Beta customers where they have run into debugging problems when using Visual Studio 2010 and targeting .NET framework 4.0. Kean Walmsley wrote an article in his blog, “Through the Interface” in April of 2010 about this issue. His article, “Hitting Breakpoints in .NET Class Libraries…” gives an explanation of the problem and different ways to work around it.
I have not run into this issue myself, but I have seen customers reproduce the problem. One of them even went through the trouble of creating a VM to reproduce it, and sent the VM to me. Switching the target platform to .NET Framework 3.5 and editing the ‘acad.exe.config’ file in the way I explained seemed to take care of the problem. There were, however, some suspicious characteristics about this VM.
First, there was no version of Visual Studio 2008 installed in the machine. I do not know if this makes any difference, but it certainly is something to look at. I have both versions of Visual Studio installed in all my computers, and I have never run into issues.
Also, the class library project was referencing some system assemblies that were never used. I do not know if their real project uses these system assemblies, but in the trim-down version they sent me they were never used. In my quick test, System.Data.dll was looking suspicious because it was not used, but the wrong version of the DLL was being loaded into memory when Civil 3D was started with the .NET 4.0 framework set as a target.
Again, if you run into problems, make sure to review Kean’s article, and the links it contains. There is a lot of information in them that might help you solve the problem. And do not hesitate to drop me a line or post a comment if you have more information, or you are not able to solve the issue. This problem really concerns us, and we need as much information as we can get.
Subscribe
Comments