Topic: VS.NET 2008 / .NET 3.5

[MaksimS]

Hi all,

Does anybody know if there are possible incosistencies when building managed-only applications for ACAD 2005/2006/2007 using VS.NET 2008 and .NET 3.5? I guess VS.NET should target specific .NET Framework version depending on the one compatible with targeted ACAD version. Are there any additional tips on this?

Regards,
Maksim Sestic

[Glenn R]

Are you having problems?

[It's Alive!]

... I guess VS.NET should target specific .NET Framework version...

With VS2008, you can target a specific frameworks 2.0 – 3.5 in your projects. Lately I have been building/testing with 3.5 and I have not had any problems. You can use the new language features on the older framework, but if you want to play with the new toys such as LinQ, PLinQ , Parallel FX library etc.. , you will need to target the new 3.5 framework.

[kpblc]

If you're create a dll loaded by _netload, you can create it only with VS 2002. To use any other Visual Studio you can work with AutoCAD as with COM-object.

[Kerry]

If you're create a dll loaded by _netload, you can create it only with VS 2002. To use any other Visual Studio you can work with AutoCAD as with COM-object.

I hate to shout and run, but ..
that statement is wrong. ... or it's an incorrect translation from another language.

[MaksimS]

Thanks for the answers.

Just to explain a bit - I'm thinking of switching from VS.NET 2005 to VS.NET 2008. I need to keep my existing projects (pure managed code) that target ACAD/MAP 2006, 2007 and 2008 platforms (.NET 2.0). On the other hand, I don't want to run into situation where something goes wrong after I get my recompiled libraries released. I had similar situation back in ACAD 2005 days when I was switching from VS.NET 2003 to 2005, but can't actually remember if there were any quirks worth remembering

I'm aware that VS.NET 2008 enables targeting specific .NET Framework version, so I'm fixing it to 2.0 and that'll be it I guess. But what if I recompile with 3.5 in mind and NETLOAD the library into, say, ACAD 2007 on a machine with only .NET 2.0 installed - I presume that ACAD will load/run it anyways, despite targeted .NET platform, since it uses highest framework version available.

Regards,
Maksim Sestic

[It's Alive!]

It would seem, if you compile for .net 3.5, you would need the .net 3.5 framework installed on the target platform (for the BCL) as well, but you may not because it all runs atop the same CLR 2.0.. I would suspect that you would at least need to make sure that  .NET  2.0 SP1 is installed on the target platform. Just to be on the safe side, I will be recommending to my end users that they install the latest framework, although I have not yet researched a method to verify if they have.

Moving from VS2003(.NET 1.1) to VS2005(.net), changed the CLR, which was probably the reason for your “situation”

[MaksimS]

This is actually discussion for some separate topic - "Deployment strategies of managed binaries on Autodesk platforms"

I'm running two separate products targeting different Autodesk verticals (ACAD and MAP) in versions 2005...2008. One of them is based on Build, while the other is based on Bundle contract (Autodesk offers several other contract types besides pure commercial one). Each product version is tightly bound to contracted Asdk platform version/vertical. It means that I can't simply switch the major version number of my product. On the other hand, company policy enables only upgrade and patch strategies on minor and build version numbers of a product. Upgrades/Patches will not allow distribution of new installation prerequisites - i.e. new version of .NET Framework. There's also one more catch - I may rely on system patches automatically distributed by Microsoft via automatic updates. Etc, etc. Keeping it all running is far from trivial, so every development environment switch seems like a slight nightmare

If any of you need an advice on this, I'll be glad to help.

Regards,
Maksim Sestic

It would seem, if you compile for .net 3.5, you would need the .net 3.5 framework installed on the target platform (for the BCL) as well, but you may not because it all runs atop the same CLR 2.0.. I would suspect that you would at least need to make sure that  .NET  2.0 SP1 is installed on the target platform. Just to be on the safe side, I will be recommending to my end users that they install the latest framework, although I have not yet researched a method to verify if they have.

Moving from VS2003(.NET 1.1) to VS2005(.net), changed the CLR, which was probably the reason for your “situation”