64 bit and managed code

by community-syndication | Oct 30, 2006 | BizTalk Community Blogs via Syndication

This article covers some 64 bit aspects regarding managed code and COM+ applications. The 64 bit info regarding managed code was taken from Josh Williams’ blog and I want to thank him for putting all this useful information online. Personally, I found his postings very usefull. The COM+ application info I was able to find it in the documentation for CoCreateInstanceEx and CLSCTX enumeration.

Josh’s articles cover mostly the subject of porting managed code EXE apps to 64 bit. Here are some links that you will find very useful:

1. Behavior of 1.0/1.1 managed apps on 64bit machines


2. What is the WOW64 and what does it mean to managed apps that you run on 64bit machines?


3. How the OS Loader will force .Net v1.0/1.1 executables to run under WOW64 on a 64-Bit Machine

If you don’t have the patience to read these articles, here’s my scaled down summary with explanations removed:

• AMD64 – 64 bit processor designed by AMD, initially named X86-64. Intel has its own compatible processors under the names EM64T, IA-32e, or Intel 64. x86-64 and x64 names are used by vendors to refer to these processors.


• IA64 – a 64-bit processor architecture developed cooperatively by Intel Corporation and Hewlett-Packard


• Once a process is started up as either 32bit or 64bit all of the dlls/assemblies that are loaded into that process have to be compatible with that bitness. Incidently, the same is true about the .Net Framework version loaded in the process.


• .Net 1.0 and .Net 1.1 EXE applications running on a 64 bit machine will run in 32-bit runtime in WOW64 mode. The selection of the .Net Framework (1.0, 1.1 or 2.0) will be determined by the CLR’s loader policy, just as it would be on a 32-bit box.


• If you know that your .Net 1.0 or .Net 1.1 EXE app is safe to be run in 64 bit mode, you can run CorFlags.exe with the /UpgradeCLRHeader parameter on your EXE in order to upgrade the IMAGE_COR20_HEADER runtime version to 2.5 (version number for .Net Framework 2.0). This will make your EXE to run as 64 bit app on a 64 bit machine. A v1.0/1.1 image which has had its MinorRuntimeVersion whacked will still be compatible with the v1.0/1.1 runtimes.


• .Net 1.0 and .Net 1.1 assemblies can be loaded and executed as 64 bit native into a 64 bit process. This can be done even without setting the IMAGE_COR20_HEADER runtime version to 2.5. If you make a .Net 2.0 executable and link against a v1.0/1.1 dll you will be able to load it into your process as if it was a .Net 2.0 MSIL assembly. If that v1.0/1.1 dll has code that isn’t safe to run in 64-bit mode it may crash.


• .Net 2.0 when installed on a 64 bit machine it will also install the 32 bit version of the framework. .Net 2.0 32 bit version will be installed in \WINDOWS\Microsoft.Net\Framework just as it would on a native 32bit machine whereas the 64bit version ends up in \WINDOWS\Microsoft.Net\Framework64.


• .Net 2.0 EXEs and DLLs have bitness information attached at compile time. CLR headers of your PE image can be marked with one of four things: MSIL, x86, x64, IA64 (names vary). You can chose how the assembly is being compiled, by default MSIL.




• x86 EXE – runs fine on 32 bit, runs in WOW64 mode on 64 bit


• x64 EXE – runs as 64 bit on x64 machines, raises BadImageException on anything else (including IA64)


• IA64 EXE – runs as 64 bit on IA64 machine, raises BadImageException on anything else (including x64)


• MSIL EXE (aka anycpu/neutral/agnostic) – the assembly is not processor specific. It runs as 32 bit on x86 machines, as 64 bit on x64 and IA64 machines.

The articles above, however do not cover the COM+ application case. Let’s say I have an out-of-proc managed COM+ component. This component is implemented as a C# class derived from ServicedComponent with attribute ApplicationActivation set to ActivationOption.Server. The assembly containing this component was compiled using .Net 2.0 and it’s marked as anycpu/MSIL. This means that the assembly and component are processor neutral and it can run as both 32 and 64 bit on a 64 bit machine. Because the server is out-of-proc, the client and server do not need to share the same bitness. The client can be 32 bit and the server 64 bit, or viceversa. This can be used successfully to integrate legacy 32 bit components into 64 bit applications. Here’s an article named 64-bit Insider that covers this aspect.

When a client app instantiates this component, the COM+ component will be created in its own process. Will that process have the same bitness as the client, will it have the bitness determined by the COM+ application settings or by the managed code setting? This article http://windowssdk.msdn.microsoft.com/en-us/library/ms693716.aspx about CLSCTX (paramater to CoCreateInstance) shades some light on some of these aspects, so I included some of the information here. Here’s my summary:

• the client of the COM+ application can control the bitness of the server process by passing in CLSCTX_ACTIVATE_32_BIT_SERVER or CLSCTX_ACTIVATE_64_BIT_SERVER (when calling CoCreateInstanceEx).


• the server COM+ component can have its own bitness setting. If the client passes in one of the values above, the client value will overide the server value.


• If neither the client nor the server specifies a preference then




• on Windows XP or Windows Server 2003 without SP1 – 64 bit will be tried first with fallback to 32 bit in case of failure


• on Windows Server 2003 with SP1 or later – the server will match the client architecture first, and it will fallback to the alternative in case of failure

The table below taken from MSDN documentation shows the results of the various combinations of client architectures and client settings and server architectures and server settings.

I hope you found this information useful.

¹ CLSCTX_ACTIVATE_32_BIT_SERVER.

² CLSCTX_ACTIVATE_64_BIT_SERVER.

³ PreferredServerBitness registry value = 1. See PreferredServerBitness.

⁴ PreferredServerBitness registry value = 2.

⁵ PreferredServerBitness registry value = 3.

⁶ PreferredServerBitness registry value is missing and Windows Server XP or Windows Server 2003 without SP 1 or later is installed.

⁷ PreferredServerBitness registry value is missing and Windows Server 2003 SP 1 or later is installed.

⁸ Fails with CO_CLASSNOTREG error.

⁹ A 64-bit server is activated if it exists; otherwise a 32-bit server is activated.

¹⁰ A 32-bit server is activated if it exists; otherwise a 64-bit server is activated.

BizTalk Server 2004 SP 2 is released

by community-syndication | Oct 30, 2006 | BizTalk Community Blogs via Syndication

InfoWorld’s BizTalk 2006 review (Oct 2006)…!

by community-syndication | Oct 29, 2006 | BizTalk Community Blogs via Syndication

Just saw this from the BizTalk Team. A great result for BizTalk 2006. Infoworld has posted thier Oct 2006 review of BizTalk 2006 and given it thier highest rating….

Check out the article: BizTalk 2006 deftly connects enterprise apps

New BizTalk Team EDI and B2B Blog.. (BizTalk 2006)

by community-syndication | Oct 29, 2006 | BizTalk Community Blogs via Syndication

OK, so no hiding the fact I have been a little behind on my blog posts over the last several weeks 😉 It’s somewhat old news now but in case you did not know, the BTS team in Redmond have launched a new B2B / EDI blog to keep us all updated. It’s at http://blogs.msdn.com/biztalkb2b/default.aspx

BizTalk 2006 Training with QUICKLEARN?

by community-syndication | Oct 29, 2006 | BizTalk Community Blogs via Syndication

While I was over in Redmond a couple of weeks ago, I caught up with Ginny Simmons from QuickLearn. I have been wanting to bring QuickLearn back to Australia / NZ to deliver some deep dive BizTalk 2006 courses, but really need to get some momentum here locally (i.e. partners and customers registering their interest / willingness to attend)! What struck my interest was the BizTalk courses they now have on offer….

• Building SOA Solutions
• BizTalk Server 2006 Quickstart
• BizTalk Server 2006 DeepDive (R2)
• BizTalk Server 2006 RFID QuickStart

I’m really keen to try and organise an RFID course here locally in Aus….. I need to liaise with Ginny to determine when the schedule starts, but please let me know if you are keen and I’ll see what I can get organised. Check out the brochure here

Microsoft releases Visual Studio 2005 IDE Enhancements

by community-syndication | Oct 29, 2006 | BizTalk Community Blogs via Syndication

Visual Studio 2005 IDE Enhancements are a set of Visual Studio extensions that are designed to make you more productive. These enhancements are directly integrated into the Visual Studio IDE. This set of enhancements includes Source Code Outliner, Visual C++ Code Snippets, Indexed Find, Super Diff and Event Toaster tools. All these tools except the IDE Event Toaster can be invoked from Visual Studio’s View.OtherWindows menu group. The Event Toaster tool can be configured from the Tools Options dialog under the PowerToys node. The Visual C++ Code Snippets can be invoked on any C++ source file. Previously, these enhancements were only available via the Visual Studio 2005 SDK. This installation does not require Visual Studio 2005 SDK.

Source Code Outliner : The Source Outliner tool is a Visual Studio extension that provides a tree view of your source code’s types and members and lets you quickly navigate to them inside the editor.

Visual C++ Code Snippets:The Visual C++ Code Snippets tool lets you insert snippets in your code by using a pop-up menu that contains programming keywords. VB.NET and C# languages have this functionality in Visual Studio 2005.

Indexed Find : The Indexed Find tool is a Visual Studio extension that uses the Microsoft Indexing Service to provide improved Search capabilities to the integrated development environment (IDE). It sends the results of a search to the Output Window.

Super Diff Utility: The Super Diff Find tool is a Visual Studio extension that compares text files. It uses color coding and graphics to show the difference between the files in deleted text (red), changed text (blue), inserted text (green).

Event Toaster Utility: The Event Toaster tool is a Visual Studio extension that notifies users about specific events within the Visual Studio IDE.

Link 

BizTalk server 2004 SP2

by community-syndication | Oct 29, 2006 | BizTalk Community Blogs via Syndication

BizTalk Server 2004 SP2 is available now. Check out the new list of bugs that are fixed in this SP2.

VSS and daily builds

by community-syndication | Oct 28, 2006 | BizTalk Community Blogs via Syndication

Ah, the joys of the mighty incomparable Visual Source Safe. In combination with VS2003 Web Projects and IIS it can send any developer over the edge of Mount Doom. It wields more power and more malice than Sauron himself.

Sometime ago we had so many problems with VSS and web projects we were actively considering moving to Subversion  (this is at my client site, in my own company we saw the light long ago and moved out of VSS to CVS and now SubVersion, but thats another story). Im keen on using TFS but thats in an evaluation phase now and since we are still working on a .NET 1.1 project (with Biztalk04) we had to make do with VSS. Just when we were about to setup the SVN repository some of the folk on the team felt comfortable that we had found a workaround with VSS web projects and so we dropped the move. Bad mistake. Now we are sort of nearing the end of the current phase of the project and were working on the build scripts. We are not yet into the CI world, its still in the automated build stage (or actually, the half automated build stage because of the aforementioned glorious product). The scripts reported some build failure in one application so  we happily opened VS to check it. Boom.. first error. VSS doesnt like you opening solutions directly like that. It has to be done through the “Open From Source Control” mechanism. This messed up the solution for a bit but we eventually  got a few projects open and corrected some of the issues. For instance I couldnt keep my solution files in their own folder because there was a MSI project in the set and it complained that the MSI project was in a different part of the structure from the solution, so i had to recreate the entire source tree for that section. Thank goodness for the GDN SourceSafeBindingRemover app. It let us make several passes at re-setting up the tree.

Set the build up again and yet another crash. This time, no matter how we tried to open the solution, IIS wouldnt let us. It just kept throwing vague errors about being unable to find the csproj file. We tried for 4 hours (including reinstalling IIS) but no luck. So finally we gave up and for that one project we put in a file copy task to get the code from a file system backup. It was rather sad and we didnt wanna do that, but there was no way to get beyond this error. The build scripts are back on track and we’ll keep them that way till we can move to TFS or maybe back to SVN. Anything to get away from this monster.

One thing i hate most about VSS is the way its a sort of control freak. As long as you let it dictate the place you store your web app files (and keep them in wwwroot, away from the rest of your code base) and let VS create the solution folders in whatever way it knows best, its all fine. The moment you try to create a disciplined source tree and keep your web projects together with the rest of the code, thats the start of all suffering. I used SVN in a previous project and never heard a murmur from the system. It just worked!! In the old days, when i started out, (in 1996) we used VC 1.52c and VB4 and VSS was fine for all that (with small teams of course), but when web apps came out, they should have done some thorough revisions, especially when you have seriously good open source competition. Its amazing that after so many years, MS still hasnt managed to get VSS to work decently with web projects. And now, the only MS option is the costly TFS. Just google for VSS and web apps problems and you’ll probably get a million results. I nearly laughed out loud when i saw one of the results was an old teched hands on lab for setting up a “builld lab” with VSS and VS2003!!

yeah, i know, someone is going to reply saying RTFM, theres a way to work with web projects, there are workarounds and all that. I’ve heard it all before. There is just no reliability with it. An automated build should at least let you sleep easier at night not keep you awake fretting about what new horrors the results of the build will reveal and what new workarounds you should find.

VSS RIP can never come too soon for me. !

Clean Up Scripts for BizTalk

by community-syndication | Oct 28, 2006 | BizTalk Community Blogs via Syndication

Since I always have a hard time remembering where it is and what to run, there are two scripts that you can run in your non-production region that can clean up currently running orchestrations that you have already terminated and it is waiting to clear it up.

You will first need to go and create the real stored procedure bts_CleanupMsgBox (this replaces the shell that is there).

The instructions are as follows to clean it up:

1. Stop BTS.
2. Do IISRESET if you are using web services.
3. Run “bts_CleanupMsgbox” on your message box database. This will mark your instances for deletion and it will not actually delete it.
4. Run “bts_PurgeSubscriptions” on your message box database. This will purge all your messages marked for deletion.
5. Restart your BTS.

A Quick Look at BRE in BizTalk Server 2006

by community-syndication | Oct 28, 2006 | BizTalk Community Blogs via Syndication

Hi All,
Iwrote an article recently onBRE’s enhancements and new features available with BizTalk Server 2006.This article can be found at thefollowing link:
http://www.biztalkgurus.com/newsletter/TheBizTalker-volume-07.html
Please do read this article and send in your comments.