BDTF and VS2010/BizTalk 2010

Topics: General Questions
Apr 29, 2010 at 5:25 PM
Edited Apr 29, 2010 at 5:26 PM

Hello,

Using BTDF, I have successfully put together an automated TFSBuild, deploy of BizTalk solutions using VS2008, BTS2009, SQL2008, Win2008.

I now need to do the same thing on a new R2 and BTS2010 environment. First issue I encounter is the loading of the BTDF in VS2010. Has anyone managed to get the BDTF installed in Visual Studio 2010? The Add-in is not loaded and visible. Cheers

Regards

Vincent Rouet

Coordinator
Apr 29, 2010 at 5:35 PM

Hi Vincent,

I'm happy to hear that you have successfully implemented a solution using the Deployment Framework!

You must be using pre-release BizTalk code (BizTalk 2010, formerly 2009 R2).  Is that correct?  The add-in model completely changed in VS 2010 (for the better).  However, I do not have access to the pre-release BizTalk 2010 code, so I have not done any work to make the Deployment Framework compatible with it.  I'll definitely be supporting it once the product reaches RTM later this year.

Thanks,
Tom

Apr 30, 2010 at 8:52 AM

Hello Tom,

Thanks for your quick response. Yes I am using the CTP version of BizTalk2009R2 as part of a TAP program with my customer.

The BTS projects have been successfully upgraded to VS2010. I'll be using the command line to run the btdfproj. I'll post the results if that can help

Rgds

Vincent

Coordinator
Apr 30, 2010 at 3:41 PM

Thanks Vincent, please do post your results if you run into any issues.  At least that will give me an idea of how much work I'm in for later this year.  :-)

Thanks,
Tom

Jun 2, 2010 at 5:00 PM
Edited Jun 2, 2010 at 5:01 PM

Hello Tom,

I am getting back to you about the deployment with BTS2010. The version is now the BTS2010 beta1. This one is available from Ms for download.

The generated msi installs fine but then we are now hitting an issue at deployment time.

The BizTalk Application is successfully Undeployed then Deployed again.

Next step is the import of the BTS librairies into BizTalk. It fails with the error below. VS2010 forces to use the .Net Framework 4.0 so this is the version of the frmk used to build the dll. We have no choice here. Direct import in BTS via the admin console works fine.

Are some adjustments necessary in the DeploymentFramework.BuildTasks.dll? I will try to deploy your latest beta release. If you have any idea, please let me know.

Error:

C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.targets(1117,5): 
error MSB4018: The "GenerateAssemblyNamesItemGroup" task failed unexpectedly.\r
C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.targets(1117,5):
error MSB4018: System.BadImageFormatException: Could not load file or assembly
'C:\Program Files (x86)\Dgf.Bus.Core.Pivot.Invc._1_0.Schemas\1.0\Dgf.Bus.Core.Pivot.Invc._1_0.Schemas.dll'
or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.\r

Thanks a lot

Vincent

 

 

Coordinator
Jun 2, 2010 at 5:42 PM

Hi Vincent,

Thanks for following up.  I'll bet this is because we're running MSBuild 3.5 not 4.0 thus the incorrect runtime error...  I guess I'll need to make it determine which version of BizTalk is installed and switch the version of MSBuild that is used.  Currently it takes 3.5 if present, otherwise uses 2.0.  Now it will need to also recognize 4.0, but only if it's BizTalk 2010 or newer.  That means figuring out some registry keys that I can search for, and I don't currently have a BizTalk 2010 server to use for testing.

Would you mind looking in the registry on your server?  The BizTalk key so far has been HKLM\Software\BizTalk Server\3.0.  Under that was a ProductVersion value.  Is that still true for 2010?  If so, what is the ProductVersion value?  The MSBuild location was in HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5, then MSBuildToolsPath.  Is there now a ToolsVersions\4.0\MSBuildToolsPath?

Thanks much!
Tom

Jun 2, 2010 at 8:55 PM

Hi Tom,

Thanks for attending to our issue. It has not changed apparently :-)

I have opened a BTS2009 machine and I have:

HKLM\Software\BizTalk Server\3.0\ProductVersion = 3.8.368.0

HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5\MSBuildToolsPath  = c:\Windows\Microsoft.NET\Framework\v3.5\

On the BTS2010 pre-release I have:

HKLM\Software\BizTalk Server\3.0\ProductVersion = 3.9.121.2

HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\4.0\MSBuildToolsPath = C:\Windows\Microsoft.NET\Framework64\v4.0.30128\

I will check tomorrow on the BTS2010 beta1

Cheers

Vincent

 

 

Coordinator
Jun 3, 2010 at 8:01 AM

Thank you!  I just realized that you have been running the deployments from the command-line.  Are you running your dev deployments using MSBuild 4.0 not 3.5?  If so, does that work before you try the MSI deployment method?

Incidentally, you mentioned earlier being forced to use .NET 4 by VS 2010 -- but VS 2010 lets you target 4.0, 3.5, 3.0 or 2.0 in the project settings.  Whether BizTalk 2010 requires .NET 4 assemblies, I don't know.

On the MSI deployments, if dev deployments work with MSBuild 4.0 then you can edit the ServerDeploy.bat, ServerUnDeploy.bat, ServerRedeploy.bat files in the Deployment Framework program files folder to point to MSBuild 4.0's path.  That should get you by for now.

I've also completed the first round of changes to get the VS add-in installed and working with VS 2010.

Thanks,
Tom

Jun 3, 2010 at 9:02 AM

Hi Tom,

I indeed tried that after I read you. It does deploy now. I use the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe

The BTS2010 forces the use of the .Net 4.0. It is possible to change from the project configuration but you get an error warning you the only 4.0 is supported on the sdk for VS2010 of BTS2010.

Thanks for you help and your quick responses. It is much appreciated!

Vincent

Jun 3, 2010 at 11:59 AM

Tom,

All is well now.

On the command line, when we generate the msi, we use the C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe (32 bits)

When we deploy (after the msi install) on the command line, we use the C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe (64 bits). We have not tried using the 32 bits since it works fine for now like this :-)

I checked the beta 1 BTS2010 version:

HKLM\Software\BizTalk Server\3.0\ProductVersion = 3.9.187.0

Regards

Vincent

Coordinator
Jun 4, 2010 at 5:58 PM

Great, thanks.  It's good to know that my changes for 2010 should be mainly related to the VS add-in and installer, since you've had success simply by using the new MSBuild.  There is one item remaining that I need to resolve with the installer for VS 2010, then I could put out a new release that will allow you to use the normal VS add-in.

Thanks!
Tom

Sep 10, 2010 at 11:14 AM

Hi Tom,

Currently working with a client who is using

1)      Window server 2008 (64bit)

2)      VS 2010

3)      BizTalk 2010 beta

I have downloaded the latest version of the BDF (DeploymentFrameworkForBizTalkV5_0_19Beta) which I believe should work with the above platform software

but I am a hitting similar problem to the one Vincent had –

DeployComponents:

Deploying components to GAC...

"C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Framework\DeployTools\gacutil.exe" /i "..\LCC.Integration.Common.Components\bin\Debug\LCC.Integration.Common.Components.dll"

Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.30729.1

Copyright (c) Microsoft Corporation. All rights reserved.

 

Failure adding assembly to the cache:   This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.targets(1229,5): error MSB3073: The command ""C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Framework\DeployTools\gacutil.exe" /i "..\LCC.Integration.Common.Components\bin\Debug\LCC.Integration.Common.Components.dll"" exited with code 1. [C:\Projects\LCC\LCC.Integration.Common\Main\Src\LCC.Integration.Common\LCC.Integration.Common.Deployment\LCC.Integration.Common.Deployment.btdfproj]

Done Building Project "C:\Projects\LCC\LCC.Integration.Common\Main\Src\LCC.Integration.Common\LCC.Integration.Common.Deployment\LCC.Integration.Common.Deployment.btdfproj" (Deploy target(s)) -- FAILED.

 

Build FAILED.

I have installed the latest .net 4.0 SDK which includes a new version of gacutil (version 3.5.30729.1) which I have copied into the ..\deploytools folder. 

What I have noticed is the following at the start of the build process -

Starting build...

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "C:\Projects\LCC\LCC.Integration.Common\Main\Src\LCC.Integration.Common\LCC.Integration.Common.Deployment\LCC.Integration.Common.Deployment.btdfproj" /nologo /t:Deploy /p:Configuration=Debug

 Build started 10/09/2010 09:40:50.

Project "C:\Projects\LCC\LCC.Integration.Common\Main\Src\LCC.Integration.Common\LCC.Integration.Common.Deployment\LCC.Integration.Common.Deployment.btdfproj" on node 1 (Deploy target(s)).

SetWinVer:

Running on Windows V60

Detected IIS 7

Detected 64-bit OS

GetSoftwarePaths:

Using .NET Framework Install Path 'C:\Windows\Microsoft.NET\Framework\v2.0.50727'.

Using BizTalk Install Path 'C:\Program Files (x86)\Microsoft BizTalk Server 2010\'.

Using Deployment Framework Install Path 'C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\'.

Using Deployment Framework Tools Path 'C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Framework\DeployTools'.

The first line Under the GetSoftwarePaths is using v2.0.50727 of the framework, should this not be set to

the .net v4.0 of the framework to reflect the MSBuild version 4.0.30319?

One other issue seems to be the VS Add-In, my VS2010 Tools Menu has 19 BDF entries all the same,

tried uninstalling BDF then re-installing, didn’t make any difference, any thoughts?

Sorry to ramble on but I would really like the customer I am working for see the benefits of the BDF,

you have done a great job and it is still one of my must have tools in any BizTalk project, keep up the good work.

Cheers

Jim

 

 

 

               

 

Sep 10, 2010 at 11:29 AM

Hi Jim,

Is that when you do a Quick Deploy? I have also encountered this error in the 19Beta released.

But it works fine when using the first menu item "Deploy BizTalk Solution". All is deployed correctly.

Vincent

From: jmclay [mailto:notifications@codeplex.com]
Sent: vendredi 10 septembre 2010 12:15
To: Vincent Rouet
Subject: Re: BDTF and VS2010/BizTalk 2010 [biztalkdeployment:211040]

From: jmclay

Hi Tom,

Currently working with a client who is using

1) Window server 2008 (64bit)

2) VS 2010

3) BizTalk 2010 beta

I have downloaded the latest version of the BDF (DeploymentFrameworkForBizTalkV5_0_19Beta) which I believe should work with the above platform software

but I am a hitting similar problem to the one Vincent had –

DeployComponents:

Deploying components to GAC...

"C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Framework\DeployTools\gacutil.exe" /i "..\LCC.Integration.Common.Components\bin\Debug\LCC.Integration.Common.Components.dll"

Microsoft (R) .NET Global Assembly Cache Utility. Version 3.5.30729.1

Copyright (c) Microsoft Corporation. All rights reserved.

Failure adding assembly to the cache: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.targets(1229,5): error MSB3073: The command ""C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Framework\DeployTools\gacutil.exe" /i "..\LCC.Integration.Common.Components\bin\Debug\LCC.Integration.Common.Components.dll"" exited with code 1. [C:\Projects\LCC\LCC.Integration.Common\Main\Src\LCC.Integration.Common\LCC.Integration.Common.Deployment\LCC.Integration.Common.Deployment.btdfproj]

Done Building Project "C:\Projects\LCC\LCC.Integration.Common\Main\Src\LCC.Integration.Common\LCC.Integration.Common.Deployment\LCC.Integration.Common.Deployment.btdfproj" (Deploy target(s)) -- FAILED.

Build FAILED.

I have installed the latest .net 4.0 SDK which includes a new version of gacutil (version 3.5.30729.1) which I have copied into the ..\deploytools folder.

What I have noticed is the following at the start of the build process -

Starting build...

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe "C:\Projects\LCC\LCC.Integration.Common\Main\Src\LCC.Integration.Common\LCC.Integration.Common.Deployment\LCC.Integration.Common.Deployment.btdfproj" /nologo /t:Deploy /p:Configuration=Debug

Build started 10/09/2010 09:40:50.

Project "C:\Projects\LCC\LCC.Integration.Common\Main\Src\LCC.Integration.Common\LCC.Integration.Common.Deployment\LCC.Integration.Common.Deployment.btdfproj" on node 1 (Deploy target(s)).

SetWinVer:

Running on Windows V60

Detected IIS 7

Detected 64-bit OS

GetSoftwarePaths:

Using .NET Framework Install Path 'C:\Windows\Microsoft.NET\Framework\v2.0.50727'.

Using BizTalk Install Path 'C:\Program Files (x86)\Microsoft BizTalk Server 2010\'.

Using Deployment Framework Install Path 'C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\'.

Using Deployment Framework Tools Path 'C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Framework\DeployTools'.

The first line Under the GetSoftwarePaths is using v2.0.50727 of the framework, should this not be set to

the .net v4.0 of the framework to reflect the MSBuild version 4.0.30319?

One other issue seems to be the VS Add-In, my VS2010 Tools Menu has 19 BDF entries all the same,

tried uninstalling BDF then re-installing, didn’t make any difference, any thoughts?

Sorry to ramble on but I would really like the customer I am working for see the benefits of the BDF,

you have done a great job and it is still one of my must have tools in any BizTalk project, keep up the good work.

Cheers

Jim

Read the full discussion online.

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

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

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings 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

Sep 10, 2010 at 12:06 PM

Hi Vincent,
 
Thanks for the reply.
 
I was using the first menu item "Deploy BizTalk Solution", although I do have 19 entries under my Tools menu item for the BizTalk Deployment Framework, I chose the first and the last of the 19 to see if it would act differently unfortunately it didn't.
 
You said you have successfully deployed does the areas I highlighted on my original post correspond with your output -
 
Starting build...

C:\Windows\Microsoft.NET\Framework\v4.0.30319\MSBuild.exe

and
 

GetSoftwarePaths:

Using .NET Framework Install Path 'C:\Windows\Microsoft.NET\Framework\v2.0.50727'.

If I try and GAC the assembly manually it works so my gut feeling is that it points to some incompatabilty within the BDF, after all we are talking BizTalk 2010 BETA!!!

Any help would be gratefull.

Cheers

Jim

Coordinator
Sep 10, 2010 at 5:00 PM

Hi Jim,

Thanks for the positive comments!  I'm always happy to hear when people are successfully using the Framework.

The thing that's weird in your output is that it appears to be calling MSBuild 4.0, yet the GetFrameworkPath MSBuild task seems to be returning the 2.0 path instead of the 4.0 path.  Almost as if MSBuild 4.0 is running against .NET 2.0 by default..

If you run this MSBuild file through MSBuild.exe 4.0 at a Command Prompt, what output do you get?

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Test">
  <Target Name="Test">
    <GetFrameworkPath>
      <Output TaskParameter="Path" PropertyName="FrameworkDir" />
    </GetFrameworkPath>
    <Message Text=".NET Framework Install Path '$(FrameworkDir)'." />
  </Target>
</Project>

I've run BizTalk 2010 projects through the current version of the Deployment Framework without even changing gacutil.exe, and it has worked fine.  I wonder if somehow your system is running in a different default mode or if some compatibility settings are in effect.

Thanks,
Tom

Coordinator
Sep 10, 2010 at 5:02 PM

Oh, and I have not seen the multiple menu items in VS 2010 myself, but it has been reported by at least one other user.  I started some time ago rewriting how the add-in registers and un-registers with VS, but it made the process quite a bit more complex and I still have not completed those changes.

Thanks,
Tom

Sep 14, 2010 at 12:47 PM

Hi Tom,

Thanks for the reply.

I have sorted out the Tools menu item issue by doing

tools\customise\commands\reset all

which removes all the BDF entries. I then did a BDF repair (running the MSI again) and it only installed 1 entry via the tools menu item.

I am not sure but I could have had VS open when I did my original install of BDF, could this be a pointer to the issue?

Cheers

Jim

 

Sep 14, 2010 at 1:33 PM

Hi Tom,

Thanks for the reply.

I have sent you a separate reply regarding the multiple tools items issue.

However I seem to be coming across several issues regarding gacutil install/uninstall.

I have gone back and restored the original gacutil installed in the Deploytools folder by the BDF

If you gac a v4.0 component it now install’s it into

C:\Windows\Microsoft.NET\assembly\GAC_MSIL

Not as before into the C:\Windows\Assembly folder.

If you browse the GAC_MSIL folder you will see all the BizTalk assemblies appearing as they are being gac’d by the deployment tool but not the components assembly.

If you then run (using the new windows 7 SDK command prompt) a gacutil e.g.

gacutil -l MyAssembly

the assembly is in the gac just not being displayed via windows explorer for any of the gac folders including the windows assembly folder, confused VERY.

Another issue appears to be when you run an undeploy using BDF when it runs the gacutil -u against a BizTalk assembly it doesn’t find them

therefore does not uninstall them, again confused VERY.

It is almost like it knows when using gacutil -i to deploy a BizTalk assembly and that has been built with v4.0 of the framework it knows to deploy it into

..\..\GAC_MSIL but when uninstalling it is looking in c:\windows\assembly folder, this is only a guess but something is not quite right.

What I would like to do is send you my BDF output for Deploying an app and an undeploy of the same app,

is there any way I can send them as files to you rather than copying/pasting then into this reply?

Cheers

Jim

 

Coordinator
Sep 14, 2010 at 7:34 PM
Edited Sep 14, 2010 at 7:35 PM

Hi Jim,

I guess I should ask if you are actually seeing a problem with your app not running or deploying properly.  What you're describing sounds like normal behavior of .NET 4.0.

From the .NET 4.0 docs:
"Beginning with the .NET Framework version 4, the Assembly Cache Viewer (Shfusion.dll) is obsolete and has been removed. Use Gacutil.exe (Global Assembly Cache Tool) to view and manipulate the global assembly cache.
[TFA: This provided the nice view of the GAC in Windows Explorer when you browse to c:\windows\assembly.]

NOTE: There might be older versions of Shfusion.dll on your computer. When you view the global assembly cache in Windows Explorer, these older versions of the shell extension will continue to be invoked. Do not use them. They do not display .NET Framework 4 assemblies or assemblies built using the .NET Framework 4."

So you should not see any .NET 4.0 assemblies in C:\windows\assembly nor in Windows Explorer at C:\windows\assembly.  Some of the BTDF assemblies, like SSOSettingsFileReader, are .NET 2.0 so they still show up there, but your BizTalk 2010 project assemblies will not show up there.  Instead, they should end up under C:\windows\microsoft.net\assembly with no GUI available to view them.

So is there actually a problem or you've just noticed the .NET < 4.0 vs 4.0 behavior?

Thanks,
Tom

Coordinator
Sep 14, 2010 at 7:39 PM

Also, you mentioned that your Components assembly is not showing up in the new GAC location -- have you gone into the Components project settings and changed the target framework version to 4.0?

I installed BizTalk 2010 Beta today, opened the BasicMasterBindings sample solution, let it upgrade the projects to 2010 format, built the solution, hit Deploy, and it deployed successfully.

Thanks,
Tom

Sep 15, 2010 at 10:40 AM

Hi Tom,

Once again thanks for the replies.

I think I have found part of the cause of my confusion, although I still think there are issues, I am convinced these issues surround the different versions of gacutil.

Using your BizTalk sample app when it is converted from VS 2008 to VS 2010 the conversion leaves the Components assembly at v3.5.  but changes the

BizTalk assemblies to v4.0.

So when you do a deploy it does deploy correctly to BizTalk and gac's the BizTalk assemblies into C:\Windows\Microsoft.NET\assembly\GAC_MSIL,

the Components assembly is gac'd into the c:\Windows\Assembly folder which again is correct for v3.5 assemblies.

If you run another BDF deploy all works fine, if however you run a BDF undeploy it does not remove the BizTalk assemblies from the gac but

it does remove the components assembly, which is why I think there is an issue with gacutil, because it does a

gacutil /u on BizTalk assemblies before doing a BTSTask RemoveApp, which is clearly not removing the BizTalk assemblies from the gac.

Now if you then change the sample app's Components assembly to v4.0 re-compile then do another BDF deploy you get the following error

DeployComponents:

Deploying components to GAC...

"C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Framework\DeployTools\gacutil.exe" /i "..\BizTalkSample.Components\bin\Debug\BizTalkSample.Components.dll"

Microsoft (R) .NET Global Assembly Cache Utility. Version 2.0.50727.42

Copyright (c) Microsoft Corporation. All rights reserved.

 Failure adding assembly to the cache: This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded.

C:\Program Files (x86)\MSBuild\DeploymentFrameworkForBizTalk\5.0\BizTalkDeploymentFramework.targets(1229,5): error MSB3073: The command ""C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Framework\DeployTools\gacutil.exe" /i "..\BizTalkSample.Components\bin\Debug\BizTalkSample.Components.dll"" exited with code 1. [C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Samples\BizTalk2009\Advanced\BizTalkSample.Deployment\BizTalkSample.Deployment.btdfproj]

Done Building Project "C:\Program Files (x86)\Deployment Framework for BizTalk\5.0\Samples\BizTalk2009\Advanced\BizTalkSample.Deployment\BizTalkSample.Deployment.btdfproj" (Deploy target(s)) -- FAILED.

Build FAILED.

this again indicates an issue with gacutil.

Moving back to my intial problem, the reason for having a Components assembly set to v4.0 is I need to add a reference to our BizTalk Schemas project,

which then forces me to make the Components assembly as v4.0 which results in the above error.

My workaround is to set IncludeComponents property to false run a BDF deploy then manually gac the components assembly using

gacutil /i at the Windows 7 SDK command prompt, this successfully installs this into the proper gac @  C:\Windows\Microsoft.NET\assembly\GAC_MSIL along with

the other BizTalk assemblies.

Once again sorry for such a long drawn out explanantion but I was really confused as to where (or if) there was an issue, but I am sure there is and it

relates to the use of gacutil, and possibly BTSTask AddResource -option:GacOnAdd,....

Cheers

Jim

Coordinator
Sep 15, 2010 at 7:41 PM
This discussion has been copied to a work item. Click here to go to the work item and continue the discussion.
Coordinator
Sep 15, 2010 at 7:45 PM

Got it.  Sorry, I had not put in a class library project set to .NET 4.0.  Most of my solution will just be to install the newer GacUtil.exe when I detect BTS 2010.  I think you were able to deploy when you replaced the included GacUtil.exe with the .NET 4 version, right?  I have another issue with deploying the PDB files to the GAC, but that shouldn't kill the deployment (and can easily be disabled if it does).

Thanks,
Tom