Deploying 64 bit package to 32 bit server

Topics: Issues 1: Installing the Component
Aug 17, 2010 at 6:09 PM

Is it possible to develop a SSIS package with the 64 bit kimballscd and deploy it to a 32 bit server running the 32 bit kimballscd?

Coordinator
Aug 18, 2010 at 4:17 AM

Absolutely - this should be true for ALL packages developed with SSIS - regardless of what custom components or tasks you happen to use.  The only case where you get into trouble with 32/64 bitness (in my experience) is with ODBC drivers and Office (Excel/Access) (see here for more info).

Why?  First - even though you may be developing packages on a 64-bit system (as I do) - you should note that BIDS (Visual Studio) is a 32-bit only environment.  At design-time, when you are developing your package on the Control Flow and Data Flow surfaces, you are using the "32-bit version" of the component.  (I used quotes there on purpose - I'll explain in a bit.)  When you run your package inside BIDS - in "debug" mode - you have a choice as to whether you execute in 32-bit or 64-bit... but only if you're running a 64-bit OS.  Again, see here for how you can specify what environment you want to debug in.  In "production" runtime - when you're using Agent or some other scheduler to run the package through DTExec or in code, you can choose what bitness to execute in by running the 32 or 64-bit versions of DTExec, or by running the API calling process in 32- or 64-bit process space.

Now - in my case, the Kimball SCD and most every other task and component is compiled to be bit-agnostic.  If you look at the DLL in your GAC (C:\Windows\Assembly) you'll see that in the "Processor Architecture" column, it says "MSIL".  MSIL is Microsoft Intermediate Language, an architecture-independent semi-compiled form.  It's not compiled to machine code yet when it's in this state.  When DTExec loads up the DLL, Windows compiles it into the desired bitness, then hands it to the process.

Happy SCDing!

Aug 18, 2010 at 4:03 PM

Thank you for a well written explanation. Dan

From: toddmcdermid [mailto:notifications@codeplex.com]
Sent: Tuesday, August 17, 2010 9:18 PM
To: Dan Slaby
Subject: Re: Deploying 64 bit package to 32 bit server [kimballscd:223859]

From: toddmcdermid

Absolutely - this should be true for ALL packages developed with SSIS - regardless of what custom components or tasks you happen to use. The only case where you get into trouble with 32/64 bitness (in my experience) is with ODBC drivers and Office (Excel/Access) (see here for more info).

Why? First - even though you may be developing packages on a 64-bit system (as I do) - you should note that BIDS (Visual Studio) is a 32-bit only environment. At design-time, when you are developing your package on the Control Flow and Data Flow surfaces, you are using the "32-bit version" of the component. (I used quotes there on purpose - I'll explain in a bit.) When you run your package inside BIDS - in "debug" mode - you have a choice as to whether you execute in 32-bit or 64-bit... but only if you're running a 64-bit OS. Again, see here for how you can specify what environment you want to debug in. In "production" runtime - when you're using Agent or some other scheduler to run the package through DTExec or in code, you can choose what bitness to execute in by running the 32 or 64-bit versions of DTExec, or by running the API calling process in 32- or 64-bit process space.

Now - in my case, the Kimball SCD and most every other task and component is compiled to be bit-agnostic. If you look at the DLL in your GAC (C:\Windows\Assembly) you'll see that in the "Processor Architecture" column, it says "MSIL". MSIL is Microsoft Intermediate Language, an architecture-independent semi-compiled form. It's not compiled to machine code yet when it's in this state. When DTExec loads up the DLL, Windows compiles it into the desired bitness, then hands it to the process.

Happy SCDing!

Read the full discussion online.

To add a post to this discussion, reply to this email (kimballscd@discussions.codeplex.com)

To start a new discussion for this project, email kimballscd@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe on CodePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at CodePlex.com