Defect by design



  • Today I decided to upgrade a Visual Studio 2008 project to VS2010. Something that should be easy and would fill in some spare time. Well I found out otherwise. The project in question has some managed C++ code that is referenced by some C# code. As it was a VS2008 project, the C# and C++ was targeted against .Net 3.5. However in its infinite wisdom Microsoft decided that managed C++ code in VS2010 projects should be hard coded to target .Net 4.0! So instantly my project failed to compile. After reading framework multi targeting for vc projects I had to pick my jaw off the ground. The proffered solution is to keep VS2008SP1 (and it has to be SP1) installed , and manually hack the project file. I just love this gem from that link:

    First of all VS 2008 SP1 must be installed on your system (you cannot do without SP1). This is a mandatory requirement for targeting framework version 3.5. Installing only the .NET Framework 3.5 redist won't do. C++ tools like cl.exe in VS 2010 are only capable of targeting v4.0. So to target an earlier framework version, we need the tools from that earlier version. And these tools are shipped with VS and not with .NET Framework.

    To top it all off my pure unmanaged C++ projects are also tagged as being .Net 4.0



  • WTF? If Microsoft allows its users to target older frameworks, hoow will they possibly encourage users to use their new software? Next thing you knoow, they'll be allowing people to write software that works on both their operating system and others.



  • The problem is more that VS2008 let you target .Net 1.0, 2.0, 3.0 and 3.5 fine.

    If VS2010 only allows .Net 4.0, you're likely going to encounter issues if you import any project from an earlier version of .Net ... which just so happens to be any project that is not brand new.

    Major fail, IMO.


  • Garbage Person

    @DaedalusRaistlin said:

    The problem is more that VS2008 let you target .Net 1.0, 2.0, 3.0 and 3.5 fine.

    If VS2010 only allows .Net 4.0, you're likely going to encounter issues if you import any project from an earlier version of .Net ... which just so happens to be any project that is not brand new.

    Major fail, IMO.

    Oh, it allows it just fine... For C# and VB.net. Hell, even F#, which was just introduced with .net 4 seems to compile in .net 2.0 mode.

     VC++ is 4.0 only. Doesn't even have the dropdown. I expect the return of C++ back versions in VS2k10 SP1.

     

    This actually pissed me off just last night because I was looking at some example DirectX code (for using DX from C#, which is needlessly complex and involves writing C++ anyway) and all the examples were from VS2008 - which meant I had to forward convert them and then fix all sorts of stupid issues related to needing to move everything up to framework 4.



  • VS2010 also force-upgrades test projects from older versions, to Framework 4.0.

    As Joel Spolsky said, the idealists at MS have won out over the pragmatists, and us ordinary developers lose as a result.



  • @The_Assimilator said:

    As Joel Spolsky said, the idealists at MS have won out over the pragmatists, and us ordinary developers lose as a result.
    Don't blame them too hard, after all they had more important work to do, such as implementing thumbnails in the IDE.



  •  VS2010 is just VS2008 with different defaults anyway.



  • Found Another WTF

    So I bit the bullet and move my C# code to .Net 4.0 so that I can match framework levels with the managed c++ code. In order to do so VS2010 has to unload and then reload the c# project which ended up with the reference to the c++ being invalidated. So I try to delete and re-add the reference but that fails with a wonderful error dialog box saying that I can only add references to DLL's and EXE's (WTF do you think I was trying to do VS2010?!?!?!).

    Googling for the solution turns up [cli c project cannot be referenced from c project allowing only assembly dll]. From this I see several people with a similar problem to me, and it looks like the problem is an extra "\" in the managed C++ projects output directory path.

    In the original VS2008 project, the path was

    $(SolutionDir)\$(ProjectName)\$(Configuration)\

    But in VS2010 it seems that the $(SolutionDir) macro has ended up with a trailing "\" so that I ended up with a directory path like

    c:\projects\thisproject\solution\\projectname\configuration\

    VS2010 can't cope with that extra "\" and either the macro has changed since VS2008, or VS2008 could cope with the extra "\" So now I am changing all of the output directories to be

    $(SolutionDir)$(ProjectName)\$(Configuration)\



  • @ender said:

    they had more important work to do, such as implementing thumbnails in the IDE.
     

    The order to turn off thumbnails by default was deemed "draconian"?

     

     



  • @Schlagwerk said:

     VS2010 is just VS2008 with different defaults anyway.

     

    Not at all, VS-2010 is a (nearly) complete re-engineering of the IDE.

     On the topic of .NET 4.0 only for VC++ 10.0, I happen to be one who agrees with this decision [No, I do not work for Microsoft, nor represent them in any way]. C++ (and even C++/CLI) deals at a much lower level than "pure managed languages" the overhead of creating a tool that supported a completely different runtime [remember 2.0 thru 3.5 were all the SAME runtime, just with incremental ADDITIONS] would have incured too much overhead.

     FWIW: The statement that you "Must have VS-2008 SP1" installed is a bit misleading. It is the easiest and supported way, but Visual Studio is completely configurable [it is JUST a shell]. It is certainly possible to set up a configuration where the VC++ 9.0 tools are invoked from within the 2010 shell, and it is even possible [using third party items] to dynamically "synthesize" a version 9.0 project file to pass to the tools from the 10.0 project file. I know...I have been doing it for months.

     



  • @Schlagwerk said:

     VS2010 is just VS2008 with different defaults anyway.

    My co-worker would suggest otherwise, after discovering that it compiles a particular set of projects [b]significantly[/b] faster than 2008 on a given system (over twice as fast, as I recall).



  • @Weng said:

    I was looking at some example DirectX code (for using DX from C#, which is needlessly complex and involves writing C++ anyway)
    DirectX for Managed Code. It's deprecated, and just as needlessly complex, but they're still shipping it even in Windows 7 and I can testify that it works. Or SlimDX. Or, if you're developing a game with no possibility for end-user customization, XNA is complicated but more goal-oriented.



  • @TheCPUWizard said:

     On the topic of .NET 4.0 only for VC++ 10.0, I happen to be one who agrees with this decision [No, I do not work for Microsoft, nor represent them in any way]. C++ (and even C++/CLI) deals at a much lower level than "pure managed languages" the overhead of creating a tool that supported a completely different runtime [remember 2.0 thru 3.5 were all the SAME runtime, just with incremental ADDITIONS] would have incured too much overhead.

    MS supports every other combination of frameworks and CLR runtime for all the other languages, so they certainly know how to build tools that support more than .Net 4. By not porting these changes to their C++ tools they are showing that it is a political rather than technical reason that managed c++ only supports .net 4 (and hence clr 4) in VS2010. And doing so while breaking functionality in their flagship development product is insulting to their customers in the very least.

    @TheCPUWizard said:

     FWIW: The statement that you "Must have VS-2008 SP1" installed is a bit misleading. It is the easiest and supported way, but Visual Studio is completely configurable [it is JUST a shell]. It is certainly possible to set up a configuration where the VC++ 9.0 tools are invoked from within the 2010 shell, and it is even possible [using third party items] to dynamically "synthesize" a version 9.0 project file to pass to the tools from the 10.0 project file. I know...I have been doing it for months.

    You say that installing VS2008 is the easiest and supported way yet seem to imply that it is not the only way, but where do you get these tools without installing VS2008?



  • @OzPeter said:

    ...The project in question has some managed C++ code...

    Everyone, please welcome TRWTF to the party!



  • @The_Assimilator said:

    VS2010 also force-upgrades test projects from older versions, to Framework 4.0.

    As Joel Spolsky said, the idealists at MS have won out over the pragmatists, and us ordinary developers lose as a result.

     

    Funny, this made me think of Joel too, but a different article of his.  It's hard not to look at Microsoft not using .NET in any significant product, and especially the new web version of Office being 100% Silverlight-free, without wondering if it isn't all a big joke they cooked up to put the rest of us at a perpetual competitive disadvantage...



  • @OzPeter said:

    MS supports every other combination of frameworks and CLR runtime for all the other languages, so they certainly know how to build tools that support more than .Net 4. By not porting these changes to their C++ tools they are showing that it is a political rather than technical reason that managed c++ only supports .net 4 (and hence clr 4) in VS2010. And doing so while breaking functionality in their flagship development product is insulting to their customers in the very least.
     

    There is a world of difference between a managed language and something that compiles directly to native code. You seem to be ignoring that point. The other languages use meta-data from the referenced items and are straight forward to adapt [simply look at different meta data sources]. C++ relies on a much lower level.

    @OzPeter said:

    You say that installing VS2008 is the easiest and supported way yet seem to imply that it is not the only way, but where do you get these tools without installing VS2008?

    You are correct in that the only supported way to get the C++ tools are via VS-2008 - Unlike the .NET environment where the compilers/tools are available as part of the SDK. My intent was that you do not have to be "switching" between using VS-2008 and VS-2010 to accomplish your task. If you have been developing using V-2008 then it is already there and one would therefore not have to "install" onto the machine at the time when VS-2010 gets used. For a "fresh" machine, you would have to do at least a minimal install of VC++.

     



  • @ender said:

    @The_Assimilator said:
    As Joel Spolsky said, the idealists at MS have won out over the pragmatists, and us ordinary developers lose as a result.
    Don't blame them too hard, after all they had more important work to do, such as implementing thumbnails in the IDE.
    Eh...The thumbnails have been available since at least VS 2005. Don't remember if VS2003 had it.



  • @TheCPUWizard said:

    There is a world of difference between a managed language and something that compiles directly to native code. You seem to be ignoring that point. The other languages use meta-data from the referenced items and are straight forward to adapt [simply look at different meta data sources]. C++ relies on a much lower level.

    Managed c++ (and I really am showing my age as it should really be referred to as c++/cli) is a fully CLR and CTS compliant language that runs in the .net platform. C# is also a fully CLR and CTS compliant language. How is it that the c# toolset in VS2010 can easily support all .net and clr versions while the c++/cli cannot? You seem to believe that c++/cli compiles to native code.

    @TheCPUWizard said:

    You are correct in that the only supported way to get the C++ tools are via VS-2008 - Unlike the .NET environment where the compilers/tools are available as part of the SDK. My intent was that you do not have to be "switching" between using VS-2008 and VS-2010 to accomplish your task. If you have been developing using V-2008 then it is already there and one would therefore not have to "install" onto the machine at the time when VS-2010 gets used. For a "fresh" machine, you would have to do at least a minimal install of VC++.
    My point is that the supposed "upgrade" to VS2010 forces you to support 2 toolsets where previously only one was needed.



  • @OzPeter said:

    Managed c++ (and I really am showing my age as it should really be referred to as c++/cli) is a fully CLR and CTS compliant language that runs in the .net platform. C# is also a fully CLR and CTS compliant language. How is it that the c# toolset in VS2010 can easily support all .net and clr versions while the c++/cli cannot? You seem to believe that c++/cli compiles to native code.

     a) Managed C++ and C++/CLI (strictly speaking) are two completely different languages.

     b) If c++/cli was restricted to ONLY producing MSIL (e.g. "ref class" "value class") then you would be correct, and I am willing to bet that Microsoft would have provided multi-runtime support. However, there is limited benefit to developing pure managed code in C++ [there are some]. The primary use case is the ability to mix (even within a single file) true C++ native code, with CLR/MSIL code.For the majority of projects I have been involved with [over 30 projects with about a dozen different clients/teams], and others that I am aware of, this is the driving force for selecting C++/CLI. Under these conditions, the native portion of the code must be intimately aware of the details of the CLR portions to a degree that does not apply when in a pure CLR environment.

    Consider the case where a C# (or other managed language) is compiled targeting one version of the CLR, and is then re-mapped to actually execute under the context of a different runtime version. Now imagine that you are writing native code [in MASM or equivilant] and need to be able to call these functions, regardless of how they happen to be mapped in a runtime configurable manner!



  • @TheCPUWizard said:

    If c++/cli was restricted to ONLY producing MSIL (e.g. "ref class" "value class") then you would be correct, and I am willing to bet that Microsoft would have provided multi-runtime support. However, there is limited benefit to developing pure managed code in C++ [there are some]. The primary use case is the ability to mix (even within a single file) true C++ native code, with CLR/MSIL code

    There is c++/cli code and there is native c++ code. You cannot mix and match them. c++/cli is always msil. All you can do is mix compilation units of different types and use defined boundaries to exchanged information between the two systems when they are stitched together with the linker. Those boundaries were well understood in VS2008 and I can see nothing in .Net 4 that changes that understanding to the point that the VS2010 toolset could not be encouraged to work as expected.

    And BTW before you say "#pragma unmanaged" all that does is effectively create an anonymous native c++ compilation unit and decorate it with pinvoke - producing effectively the same system as if you had explicitly linked c++/cli to to native code.



  • @Schlagwerk said:

     VS2010 is just VS2008 with different defaults anyway.

    Wow, seriously? I tried it and was shocked at how different it was. Even the freakin' drop down menus have changed. (For no good reason.)



  • @blakeyrat said:

    @Schlagwerk said:

     VS2010 is just VS2008 with different defaults anyway.

    Wow, seriously? I tried it and was shocked at how different it was. Even the freakin' drop down menus have changed. (For no good reason.)

    I was shocked at how navy blue it is. I WANT MY ORANGE VS ICON BACK DAMMIT!



  • @The_Assimilator said:

    I was shocked at how navy blue it is. I WANT MY ORANGE VS ICON BACK DAMMIT!
     

    I like orange.




  • @b_redeker said:

    I like orange.
     

    It's a little known fact that Dutchmen physically look like this.

    In the daily life, they put on skin-toned makeup and wear drab clothing over their orange skin.



  • @dhromed said:

    @b_redeker said:

    I like orange.
     

    It's a little known fact that Dutchmen physically look like this.

    In the daily life, they put on skin-toned makeup and wear drab clothing over their orange skin.

     

    Seems like an exercise in futility. Since they spend all their time plugging holes in levees, the makeup must wash off quickly.



  • @Someone You Know said:

    @dhromed said:

    @b_redeker said:

    I like orange.
     

    It's a little known fact that Dutchmen physically look like this.

    In the daily life, they put on skin-toned makeup and wear drab clothing over their orange skin.

     

    Seems like an exercise in futility. Since they spend all their time plugging holes in levees, the makeup must wash off quickly.

     

    Wow, you really believe the propaganda? Holland has much advance beyond that, these days it's done with a wooden shoe and bits of cheese. No need to use little kids anymore.



  • @b_redeker said:

    @Someone You Know said:

    @dhromed said:

    @b_redeker said:

    I like orange.
     

    It's a little known fact that Dutchmen physically look like this.

    In the daily life, they put on skin-toned makeup and wear drab clothing over their orange skin.

     

    Seems like an exercise in futility. Since they spend all their time plugging holes in levees, the makeup must wash off quickly.

     

    Wow, you really believe the propaganda? Holland has much advance beyond that, these days it's done with a wooden shoe and bits of cheese. No need to use little kids anymore.

     

    Don't be so naïve. They don't have wood in Europe. 

    Abraham Lincoln invented wood so that he could build the log cabin he was born in. It's been a closely guarded national secret ever since. Dutchmen's shoes are made out of marijuana and sexual impropriety.



  • @Someone You Know said:

    Dutchmen's shoes are made out of marijuana and sexual impropriety.
     

    True story.


  • Garbage Person

    @TwelveBaud said:

    @Weng said:
    I was looking at some example DirectX code (for using DX from C#, which is needlessly complex and involves writing C++ anyway)
    DirectX for Managed Code. It's deprecated, and just as needlessly complex, but they're still shipping it even in Windows 7 and I can testify that it works. Or SlimDX. Or, if you're developing a game with no possibility for end-user customization, XNA is complicated but more goal-oriented.
    Heh, I'd considered DX for Managed Code. "Deprecated" is funny when it comes from Microsoft - it'll be supported for all eternity. But it all seemed needlessly complicated. I have a copy of XNA sitting here, but I have somewhat irrational fears that introducing that to the mix will somehow conflict with the extensive use of CrystalReports and general un-gaminess of this... Uh, well, yeah. It's a game. A game for unashamed nerds (which generally resembles Microsoft Excel more often than it resembles an actual game.

    SlimDX sounds sexy as hell.You may have just saved me a million hours and gray hairs.

     

    And while I'm talking about this project, I may as well point out its general system requirements:

    - CUDA capable video card (OpenCL coming at the library author's leisure - if a CUDA card isn't present, it'll run the physics code on the CPU and it will technically work, but you'll die waiting)
    - x64 only.
    - Roughly 4 gigs of RAM.
    - 3 gigs of disk space per game save (Why yes, a save game IS a serialized dump of assets, why do you ask? Compression will come later)
    - DirectX 11


Log in to reply