Visual Studio 2008 & .NET Framework 3.5 released

Microsoft has released Visual Studio 2008 and the .NET Framework 3.5. For the announcement see Soma's blog and for more detailed information see Scott Guthrie's.

I haven't yet worked with this version of Visual Studio, but I'm told it installs side-by-side with previous versions of Visual Studio, so I'll be taking a look after AU.

Some of the areas I'm especially interested in - and this is not an exhaustive list of all the cool stuff the release includes... 🙂

  • C#/VB language features, many of which have come from the world of functional programming
    • Automatic properties, extension methods, lambda expressions, object & list initializers, etc. etc.
  • Enhanced HTML/CSS editing
    • I still hand-hack a fair amount of HTML
  • LINQ - language integrated query
    • Allows you to create/manage data(-base) queries via code rather than SQL
  • Integrated browsing of the .NET Framework source

As for AutoCAD development: there should not be a problem writing .NET applications for AutoCAD with Visual Studio 2008 - especially as it allows you to build applications for prior versions of the .NET Framework - but you should not attempt to build ObjectARX applications. The supported C++ compiler for ObjectARX in AutoCAD 2007 & 2008 is Visual Studio 2005.

I'll be back on the subject of metaprogramming in my next post...

8 responses to “Visual Studio 2008 & .NET Framework 3.5 released”

  1. Hi Kean,

    Great blog - fantastic topics that are very relevant.

    Could you think about creating a post that outlines the 'best' way to manage compiling for multiple versions of AutoCAD within Visual Studio.

    Thanks in advance

    Adam

  2. Hi Adam,

    Thank you for the feedback.

    This is quite a broad topic, and as I'm sure you've found out, can be quite tricky. Are you personally trying to manage ObjectARX (C++) and/or .NET code/projects?

    Regards,

    Kean

  3. Hi Kean,

    Thanks for the reply.

    We already have our ObjectArx Code coming off a single code source and then being compiled in VC6,VS.NET and VS2005 with conditional compilation statements where necessary. We output xxx2k.arx, xxx2k4.arx, xxx2k7.arx. They all go in the install but the installer creates the appropriate demand loading registry keys dependant on the AutoCAD installed.

    I was now concerned with what is the best way forward for new .NET code. We would prefer early binding for the benefits of Object Browsing etc (have heard of people doing early binding and then transforming the code for late binding before release but not sure I want to do that).
    Do we have to make dlls for each version of AutoCAD 2006+? What is the best/easiest way to work off a single code base for multiple AutoCADs (let's intially assume using functionality applicable to all AutoCAD's)?

    Cheers

    Adam

  4. Hi Adam,

    Something that may help here is Visual Studio 2008's multiple targeting feature: this allows you to target a particular version of the .NET Framework, though it's not clear to me whether it can be extended/adapted to other "platforms", such as AutoCAD.

    To target multiple AutoCAD versions when using the .NET API, you should be able to use the lowest release number (although do watch out for the caveats listed in this post and its comments). You'd need to be sure that the functionality was maintained between versions, but in general that's the case.

    Cheers,

    Kean

  5. Hi Kean,

    In acad.exe.config of Autocad2008, it says Autocad always uses latest .NET Framework installed on the computer. But I found it was not the case. After .NET framework3.5 installed on my machine, Autocad2008 is still binding to .NET 2.0 assemblies. Trouble is my plugin dll is referencing.NET dlls built based on .NET3.5, therefore can not be loaded by Autocad2008. Is there any way to force Autocad2008 pick up .net3.5?

    Btw, is Autocad2009 running on .net3.5?

    Thanks,
    Simon

  6. Kean Walmsley Avatar

    Hi Simon,

    I don't know. I suggest asking your question via ADN, if you're a member, or via one of our discussion groups, if not.

    Regards,

    Kean

  7. Hi Kean,

    I was on the wrong track. It is in fact a dll binding problem. That .NET dll can be loaded if it is beside acad.exe, but not in a different folder even I have added the folder path into the Autocad profile "support file search path". Any idea about this problem?

    Thanks,
    Simon

  8. Hi Simon,

    We absolutely recommend putting yoru application inside (or beneath) the root AutoCAD application folder.

    The support file search path is not used by the .NET Framework to load assemblies.

    Regards,

    Kean

Leave a Reply to Kean Walmsley Cancel reply

Your email address will not be published. Required fields are marked *