Visual Studio 2008 implications

So VS2008 is out the door and opinions seem favourable so far. I may well move to it next year.

Why next year?

They are having a major C++ refresh out of cycle, Q1 or Q2 next year to bring in a ton of new stuff, bits of boost, and Vista MFC stuff amongst other things.

I read this as a major shift in policy for Microsoft. All non .net code has been discouraged for years, and the view seemed to be  whatever it is, if you are using MS tools and targeting Windows then thou shalt use .net (and C# in particular).

The new C++ bits coming in VS2008 say to me that MS has realised that native code is more appropriate in some circumstances. About time.

I also think this gives the C++ language on the MS platform a new lease of life. I’d love to know the reasoning behind the move. Delphis continued success?, poor adoption of CLI? Internal dev rebellion? Others?

What do you think?

Am I reading too much into it? Anyone else interested?

Of course I’ll believe they are totally committed when I see an MCSD exam in C++ (remember them?). But I still think this is a great time to be getting into C++ on Windows

I’m already looking forward to the Excel 14 SDK with lots of C++ goodness (??).

cheers

Simon

Advertisements

22 Responses to “Visual Studio 2008 implications”

  1. Stephane Rodriguez Says:

    Vista MFC? Aren’t Vista controls already replicated on a site like http://www.codeproject.com ? I wonder what’s the value proposal here, I mean aside killing the market for small UI vendors.

    If I’m not wrong, those changes include a Ribbon UI framework… ah :-)

    As for MFC and its core thread unfriendliness (AFX_MANAGE_STATE anyone), I wonder what’s the point using this library in a multi-core world. It’s definitely a NO-GO.

    Microsoft really made silent changes in Visual Studio 2005, like making it not possible anymore to statically link to MSVCRT. That is a big scenario, a show-stopper for many out there. (I personally use Visual Studio 6.0, leaving it to others the joy to be Microsoft guinea pigs, or sado-masochists, depending on how you see it). I wonder what are the surprises of Visual Studio 2008, and the ones coming later…

    Also, who knows what they’ve done again with the “security” pretext? How many run-time functions have changed their behaviors this time again?

  2. Ross Says:

    I spent the whole of Saturday, Sunday and Monday looking at XLLs and C++, was good “fun” but looked very hard and slow! – I wonder if Delphi is any better/easier/faster. I wonder if MS would consider an drop to natve (well VB6 runtimes) option for VB.Net?

    I like .Net to be honest, for standalone apps its very quick and easy to develop with, it’s such a shame that deployment with Office apps is so crap, maybe VSTO 3 is the solution, wish they had made it more compatible (97, 00, 02) though – I think shimmed managed coms are the way forward, until VSTA maybe.
    I’ll keep dipping into C++, I just bought a new book on it, but I don’t think, I’ll use it that much – It’s too hard and too slow!

  3. Stephane Rodriguez Says:

    “I think shimmed managed coms are the way forward, until VSTA maybe.”

    The mistake you make is that you assume you are alone, i.e. you are the only add-in loaded in Excel. But that’s not the case in general, hence the superiority of the controlled environment as opposed to deploying software regardless what the user is using. And you end up screwed by whatever add-in gets loaded before you. For instance, the first .NET-based add-in that gets loaded defines which version of the .NET run-time will be used. Your add-in better work well with this .NET version, even though you don’t know which one it will be. Call me crazy, this is awful, and yet this is the most general scenario I am describing here.
    Want to take a guess what happens with unsigned assemblies?

    I think Microsoft would do add-in/VSTO developers a great service, (if we are still talking about deployed software which in my opinion, is dead), they would make it not only possible but also seamless to embed .NET assemblies inside ZIP-based Excel 2007 file formats. In fact, to be able to do so would be the exact same thing we’ve been having with VBA, albeit with a different security model. I don’t understand why neither the Excel team nor the VSTO Excel team don’t have this scenario in VSTO 3. And I would find it baffling to learn that Excel 14 does not support it either. (you would have to ask those NDA people to know what to expect in Excel 14).

  4. Rob Bruce Says:

    “I think Microsoft would do add-in/VSTO developers a great service, (if we are still talking about deployed software which in my opinion, is dead), they would make it not only possible but also seamless to embed .NET assemblies inside ZIP-based Excel 2007 file formats.”

    I’ve been thinking exactly the same thing (and not just for .NET). I’ve not played with Office 2007 or its file system for about a year, but I’m wondering if maybe MS doesn’t want to take this route it’s do-able within the community.

  5. Ross Says:

    >>In fact, to be able to do so would be the exact same thing we’ve been having with VBA, albeit with a different security model.

    Yeah I was thinking this too – but would that nullify any soucre control advantages that might come with complied code? i.e. versioning?

    Stephane I would like to know more about this “first through the door” thing, I thought the shim would load the assembly into it’s own app domain, which would be calling what ever .Net framwrok it liked? Is this not the case?

  6. Stephane Rodriguez Says:

    “into it’s own app domain, which would be calling what ever .Net framwrok it liked? Is this not the case?”

    It is…if you are the first to be loaded. Otherwise, the .NET runtime is already loaded and you are bound to it. For instance, a customer uses a VSTO version or an add-in which loads .NET 1.1, and this is loaded before you : consequence is that your add-in/VSTO code better work with .NET 1.1.

    Remember that both the .NET runtime, the shim and addin are dlls, and therefore share the same running process (i.e. Excel.exe)

  7. Ross Says:

    Humm, thats a bit worrying, might have to take a look at this!
    Cheers
    Ross

  8. Simon Says:

    I may have a dabble with the new VSTO but I’m going to need some serious persuading that its ready for real world production.
    Mind you from what Stephane says I may have to go back and review my VS choice too – I’m just in the process of moving to VS2005 from VS6, might skip straight to 2008 (assuming its ok)

  9. Dennis Wallentin Says:

    Funny, I have the impression that by default the .NET framework will load the latest version of the .NET runtime for COM interop. If I want to load an earlier version I need to create a config file for Excel.

    Kind regards,
    Dennis

  10. Stephane Rodriguez Says:

    I’m talking about the situation when MULTIPLE .NET add-ins/VSTO are loaded. Let’s say you are the second to get loaded. How much control do you have on which .NET runtime is loaded?

  11. Dennis Wallentin Says:

    Stephane,

    OK, You’re right about that. .NET Framework 1.1 is the lowest version I test with as VS 2003 cannot use 2.0 or later. So far I have not had any issues with it but I can see a large number of scenarios where this may be an issue. One ‘workaround’ is to use a config file. But again, suppose other vendors also do it. (If we develop standalone tools, i e exe files, it’s not an issue).

    Although it’s an issue today I can see that it will be less in the foreseeable future as Vista is shipped with version 3.0 and VS 2008 is shipped with 3.5.

    Kind regards,
    Dennis

  12. Stephane Rodriguez Says:

    “So far I have not had any issues with it ”

    You were alone being loaded as a .NET guest?

    “One ‘workaround’ is to use a config file. ”

    You are going to change Excel.exe.config? I hope not, because it won’t be long before customers get back to you what the hell you’re doing with their system. And just so you know, for instance, Excel 2007 already has a config file, to override the Vista low-privilege execution. Therefore, any change you are willing to make on a customer machine will be a modification of an existing file, not just a copy/paste of a template config file you would send them (or worse, a template file that is in your Windows Installer that would override your customer’s config file).

    Important point : it’s not yourdll.dll.config, it’s Excel.exe.config. You don’t OWN this file.

    All I’ve been explaining here is part of the issue (this is just a fraction of the .NET mscoree decision tree for loading a version of the .NET runtime). This obviously ONLY APPLIES to the first add-in/VSTO being loaded, not to you if you are loaded after in the list of loaded add-ins/VSTO.

    “Although it’s an issue today I can see that it will be less in the foreseeable future as Vista is shipped with version 3.0 and VS 2008 is shipped with 3.5.”

    I would say the opposite. Any new .NET runtime being shipped is new trouble. You have to make sure your existing product works well because anybody out there may install the latest version whether you want it or not. If your .NET add-in/VSTO is tied to a given .NET version (for one reason or another), or does not work with the latest .NET version (in case the decision tree for loading the .NET runtime ends up loading the latest version of the .NET runtime installed on that computer) you are screwed.

    Can’t disagree more with something that is apparently overlooked a bit here. Part of the decision tree of mscoree (owned by Microsoft) is that, if the .NET runtime is not loaded already in the running process, it loads the latest .NET runtime version available if there’s no config file. But even that can be a NO-GO for you. Consider for instance the breaking changes between .NET 1.1 and .NET 2.0 (http://msdn2.microsoft.com/en-us/netframework/aa497239.aspx). I’ve lost track of .NET afterwards, but I’m sure someone out there can point at changes that have occured in .NET 3.0, and in the just-released .NET 3.5

    The more versions out there, the more troubles. I don’t think it can be overstated.

  13. Stephane Rodriguez Says:

    Back to the original thread, (sorry Simon for hijacking it with .NET), the joy of deploying C++ apps made with Visual C++ 2005 : http://blogs.msdn.com/aymans/archive/2006/04/04/568466.aspx

    I hope Visual C++ 2008 improves the situation. Anyone?

  14. Simon Says:

    Thanks for the link Stephane – back to Vs6 for me too then, or maybe 2003. I thought 2008 showed promise, now I wonder if they are moving the wrong way?
    I’m with you on .net, I’d rather focus on other things (native code). And I have big hopes for 2008 too.

  15. Dennis Wallentin Says:

    Stephane,

    First of all, You don’t need to abuse me or my customers. Second, I could give some additional info about some customized solutions but I feel that You’re attitude is totally wrong.

    Enjoy Your day,
    Dennis

  16. Stephane Rodriguez Says:

    Dennis,

    WTF?

  17. Simon Says:

    Dennis
    I didn’t read Stephanes comments as abusive, forceful, but not abusive. It might be a language thing?
    The key point I think is that you both have tonnes of valuable experience and insight in your chosen areas. Based on our experiences we all have slightly different preferences which makes for great discussions.
    I think anyone would find explaining the hidden intricacies of .net a challenge, and trying to do it clearly in a flat blog comment almost impossible.

    I value the contributions both of you make, and the different perspectives you bring, and I’m sure other sos readers do too.
    cheers
    Simon

  18. Dennis Wallentin Says:

    .NET is an enterprise development platform and by design .NET solutions targeting the Windows Desktop require a 100 % controlled environment. This is a must to fully understand as otherwise too many issues will most likely occur.

    At present I have 14 managed COM add-ins and they have been implemented in 9 different corporate (4 of them are worldwide Swedish companies). In all cases the desktop environment is controlled.

    In 2 cases I’m the owner of the Desktops environments meaning that I’m in control for, among other stuff, which version of .NET Framework will be used. In the other cases I, via support agreements, need to update my solutions whenever the corporates decide to upgrade their environments (new version of Office, Windows, Framework et al). I also got VSTO solutions shipped where I also, via support agreements, need to update the solutions whenever things are changed in the desktop’s environment.

    We can agree that we disagree, we can agree that we agree, we can be right or we can be wrong. As long as we act within these boundaries the terms should be acceptable by everyone.

    The key point is that when we don’t know the conditions for others developers we therefore should have a different approach then trying to mastering. That’s why I use the word abused.

    Kind regards,
    Dennis

  19. Harlan Grove Says:

    If .Net truly requires ‘a 100 % controlled environment’, then it’s only going to work for in-house development or COMPLETE third party solutions. Almost by definition it won’t work if .Net add-ins would only be one part of a customized configuration over which the developer of the .Net piece had no control.

    I think there may be cultural aspects to this. Certainly in the US there’d be considerable (if not overwhelming) resistance to allowing third parties to control configurations, perhaps with the exception of IBM/CSC or similarly large (well over US$1 billion in annual support revenues) 3rd parties who’d agree to configure ALL software/systems on ALL client machines. Small independent developers would seldom if ever be given any say in corporate/organizational configurations.

  20. Dennis Wallentin Says:

    >>Small independent developers would seldom if ever be given any say
    >>in corporate/organizational configurations.

    That’s why .NET based shared add-ins and VSTO are per se enterprise tools.

    So when MSFT talks about new technologies and how to implement VSTO, WPF, WFC and LINQ with Office 2007 then it’s the group of enterprises they target.

    The mentioned 2 companies in my previously comment have < 100 employees.

    I’m in the process to finalize a free managed COM add-in that target Excel 2000 – 2007. One of the more interesting aspects is to see what the major issues actually will be.

    Kind regards,
    Dennis

  21. Darren Says:

    Does the quote below from Stephane mean it should be possible to create an out of process EXE shim that can load all managed assemblies required into their appropriate appdomains? If so would this impact debugging? Obviously out of process would incur a performance penalty, but this is of little concern to my problem.

    ““into it’s own app domain, which would be calling what ever .Net framwrok it liked? Is this not the case?”

    It is…if you are the first to be loaded. Otherwise, the .NET runtime is already loaded and you are bound to it. For instance, a customer uses a VSTO version or an add-in which loads .NET 1.1, and this is loaded before you : consequence is that your add-in/VSTO code better work with .NET 1.1.

    Remember that both the .NET runtime, the shim and addin are dlls, and therefore share the same running process (i.e. Excel.exe)”

  22. Methods In Excel » Dot Disaster, Frameworks don’t work! Says:

    […] Rodriguez of xlsgen points out that the framework version Excel (office) loads first, will be the framework versions tha… The com shim does not effect this out come as it’s controlled at the Application level, i.e. the […]

Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s


%d bloggers like this: