Why do Visual Studio Extensions for WSS 3.0 not support 64-Bit Platforms?

With the recent release of VSeWSS 1.2 I have had a number of customers inquire as to why Microsoft does not provide support for 64-bit platforms. I wondered this myself as our prescribed guidance to users is to run MOSS and WSS 3.0 on 64-bit platforms. We even announced that 32-bit support will not be available in future versions. This is also rapidly becoming the standard across many of our products.  Given this, it is reasonable for customers to want their dev environments to be 64-bit as well so that there are no surprises when deploying custom code to production. 

I reached out to the product group that develops the extensions on this issue. In addition, I asked that if 64-bit support is not a priority then would they consider opening up the extensions to the development community on Codeplex. This same suggestion is found repeatedly within the comments on the product group's blog. As a result of my inquiry I received a very reasoned response from the product group that I wanted to share as I think it may help you understand why 64-bit support is problematic and also to let you know the product group understands your concerns and is currently thinking of possible solutions to this issue.

First, having your dev environment on a 32-bit platform and your production environment on a 64-bit platform should not cause issues. The artifacts in MOSS/WSS dev are .NET assemblies and thus the JIT compiler in the CLR handles the architectural differences. This is why the product group does not see a conflict in our prescribed guidance of having your farm on a 64-bit platform and your dev environment on a 32-bit platform. That said, we do recommend you test your artifacts on a 64-bit platform before deploying to production.

That is just Microsoft's way of spinning this issue you say! That is not the case at all but I understand why you might think that. Chris Johnson, Program Manager for WSS, gave the following explanation as to why 64-bit support for the extensions is problematic:

"Because the VS IDE is 32-bit, it loads plugins into a 32-bit process. That, however, is not the issue as the extensions will load on a 64-bit platform. The trouble begins when you attempt to use them. VSeWSS uses the SharePoint object model to provide certain functionality. This means that on a 64-bit platform the object model is 64-bit and this presents a problem for the aforementioned reason that VS is loaded into a 32-bit process even on a 64-bit platform using WoW.  One scenario where this is an issue is when the SharePoint object model queries the registry for items like the Config DB information.  WoW gets in the way here and queries the 32-bit registry instead of the 64-bit registry the object model expects."

So now that we know why 64-bit support is problematic, what should we do about it? One possible solution for VS 2008 would be to build an out-of-process mechanism to call the SharePoint object model from VSeWSS.  Chris Johnson informs me that this is not trivial, however, and would require a level of effort the product group does not currently have the bandwidth for. They are all busy getting the new version of SharePoint ready for us instead!

So what about open source and Codeplex you ask? While that is a reasonable suggestion, we at Microsoft have to clear many hurdles before releasing code to Codeplex. It would require a signigicant amount of time for a developer in the product group to package the code and make it ready for public distribution. As aforementioned, the product group is already tasked with other development priorities and thus does not have the bandwidth to package the extensions for open source development.

Thank you to Paul Andrew and Chris Johnson from the product group for taking the time to explain the reasons for not providing 64-bit support and for all of their hard work.  I hope this post allows you to understand the reasoning behind the decision and also helps you realize that we at Microsoft do hear your concerns and even share them most of the time.

As a reward for reading through this very lengthy post, here are some recent resources that were updated and announced at TechEd that you may find interesting:

UPDATE: VSeWSS 1.3 CTP now has 64-bit support. Read about it here.

Comments (6)

  1. (Not in my native Windows environment anyway.) I have a few spare moments at work right now. I've

  2. Henrik W H says:

    Endelig er der kommet tools til SharePoint udvikling til Visual Studio 2008 . Bemærk at du skal køre

  3. Kosher says:

    Seriously, I know I am a nay sayer with my saying of nay but SharePoint has become a serious mess.  Performance is a nightmare and now you’re saying that Visual Studio has to change its process model so that SharePoint works?  How about you guys fix the damn registry access settings to detect the 32 bit process model like everyone else does?

    It’s almost as if SharePoint is completely detached from the rest of the .NET framework devs and is off on its own little path doing its own thing.

    Please fix what you guys have going.  You and I both know that the CSS isn’t working, the performance of the js classes are slow and have been and need to be updated, and the rest of the platforms is still full of holes.

  4. scrowder says:

    So what is the suggestion for doing WSS development on my vista 64-bit machine?  

    Should I use sharepoint designer 2007?

  5. dsandor says:

    This lack of 64 bit support is ridiculous.  All of us developers in teh ‘real world’ have to contend with 32/64 interoperability issues so should you.  All the server platforms are targeting x64/64 bit OS models and so developers are adopting this platform not just for seamless dev -> test -> prod deployments.  We are making use of our development machines for larger development tasks such as sandboxing virtual machines and running different target OS versions locally.  With the consolidation of hardware resources in the IT spectrum many departments are reducing the hardware footprint to opt for beefier machines with more memory in order to support virtualization.  

    I think the product team has a misconception that the developers are simply using a 64 bit platform for deployment issues.  We know how MISL works.

    Personally is seems like the product team in this release was stretched so thin that they had to dump the 64 bit support because they were inundated with the complexities of releasing a 64 bit toolset.

    Please consider a 64 bit version of the tools as there is more urgency to this than simply deployment issues.  I mean I can’t have my entire development staff re-tool thier development workstations to an x86 platform because you guys can’t work out the interoperability issues with WoW64.

    My vote is to open these tools up to CodePlex.  The community can manage this transition.

  6. Previously I had posted the SharePoint product group’s explanation as to why VSeWSS 1.2 did not provide

Skip to main content