AppsToReference is not working on 64-bit machine

Topics: General Questions
May 15, 2011 at 8:29 PM

Hi,

   We are facing an issue due to "AppsToReference" task as it uses ExplorerOM API named "Application" to add other BizTalk application references. When we use this property, we are getting successful log messages for adding application references. However, we are not seeing any references added on the BizTalk Admin console. Finaly, we found that it is an issue with ExplorerOM API as it is not supported on 64-bit platform. This issue is really holding us to move forward on a production release. It would be really appreciated, If some one is able to help us out for the alternative approach. Thank in advance.

 

Coordinator
May 16, 2011 at 1:38 AM

You just need to use the 32-bit MSBuild instead of the 64-bit MSBuild.

Thanks,
Tom

May 16, 2011 at 3:16 PM

Thanks Tom...I am not sure how to point to 32-bit MSBuild through the deployment framework project files. Below is the only one platform settings property that i am seeing on the deployment project and it is already pointing to 32-bit platform.

<Platform Condition="'$(Platform)' == ''">x86</Platform >

Any help would be really appreciated. Thanks in advance....

Coordinator
May 16, 2011 at 3:23 PM

How are you running this deployment?

May 16, 2011 at 5:53 PM

I am using Visual Studio menu option "Tools->Deployment Framework For BizTalk->Deploy BizTalk Solution" for local deployment and "Tools->Deployment Framework For BizTalk->Build Server Deploy MSI" for server deployment. I am having the below entries on .btdfproj file,
 
<ItemGroup>
  <AppsToReference-LTC Include="BizTalk.Common"/>
</ItemGroup>


and i am having the below entries on the .targets file,
 
<Target Name="DeployAppDefinition-LTC" DependsOnTargets="UndeployAppDefinition-LTC" Condition="'$(DeployBizTalkMgmtDB)' == 'true'">

<!-- Create BizTalk 2006 application definition -->

<ItemGroupFromSeparatedList SeparatedList="$(AppsToReference-LTC)" FormatString="{0}" ReverseList="false" Condition="'$(AppsToReference-LTC)' != ''">

<Output TaskParameter="ItemGroup" ItemName="DeployAppRefsGroup-LTC" />

</ItemGroupFromSeparatedList>

<Exec Command="BTSTask.exe AddApp -ApplicationName:$(BizTalkAppName-LTC) -Description:&quot;$(ProjectName)&quot;" />

<AddAppReference ApplicationName="$(BizTalkAppName-LTC)" AppsToReference="$(AppsToReference-LTC)" />

</Target>

 

 

The value of $(AppsToReference-LTC)"  is "BizTalk.Common".  Please let me know what i have to change to make it work. Thanks.

Coordinator
May 16, 2011 at 6:23 PM

Hi,

First, are you aware that you can add application references with built-in functionality by adding an ItemGroup containing <AppsToReference> elements in your .btdfproj?  For instance:

<ItemGroup>
  <AppsToReference Include="App1;App2" />
</ItemGroup>

Second, what version of Visual Studio?  For 2005, could you please check the registry value of HKLM\SOFTWARE\Microsoft\VisualStudio\8.0\MSBuild\MSBuildBinPath?  If 2008, please check the registry value of HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersions\3.5\MSBuildToolsPath.

Thanks,
Tom

May 16, 2011 at 7:55 PM

Yes. We are aware that we can add a reference by adding ItemGroup containing <AppsToReference> elements in the .btdfproj file. We do have the below entires in our .btdfproj project file,

<ItemGroup>

<AppsToReference Include="BizTalk.Common" />

</ItemGroup> 

 

We added this entry below the property group and above the "Import" statement.  However, we are not seeing the reference added on the BizTalk admin console and when the deployment framework does the "Import" of binding file, it fails as it is not able to find the reference to the common application.  We have two BizTalk applications which are referencing the common application.

We are using Visual Studio 2008 with SP1. The value on the "MSBuildToolsPath" is "C:\Windows\Microsoft.NET\Framework64\V3.5\"

Please let me know, if you need any more details. Thanks a lot for assisting us on this issue.



Coordinator
May 16, 2011 at 8:46 PM

Sorry, I'm answering too many questions at once and didn't look at the title of this discussion!  I'm a bit mystified as to how I've never run into this myself while running on x64.  In any case, I guess the Visual Studio add-in will have to be modified to detect x64 and use the 32-bit registry hive to pull this MSBuild path.  I created an issue in the Issue Tracker.  Since Visual Studio itself is 32-bit, I'm not sure why it would ever pick up the 64-bit MSBuild path.

Have you tried building an MSI and using it to deploy to your local machine or to a server?  I suspect that it will work fine, because it always uses 32-bit MSBuild.

Can you verify that Visual Studio actually is using the 64-bit MSBuild.exe during your deployment?  I think one of, if not all, of the Deployment Framework menu items show the MSBuild.exe path at the top of the Output window.

If it really is running the 64-bit version, then for the Visual Studio add-in, the best temporary workaround is to just keep a backup of that registry key and change the value to "C:\Windows\Microsoft.NET\Framework\V3.5\" (and restart Visual Studio).

Thanks,
Tom

Coordinator
May 16, 2011 at 10:48 PM

Do you have projects in your solution configured for x64 target platform instead of x86 (or AnyCPU)?

Thanks,
Tom

May 16, 2011 at 10:57 PM

Tom,

     When we added just <ItemGroup> node on the .btdfproj, we are not seeing any references automatically added on the BizTalk admin console. However, we are able to add the references successfully by having both <ItemGroup> node on the .btdfproj file as well as <AddAppReference> node on the "DeployAppDefinition" Target node (.targets file). The local deployment is working fine now. Can you please let us know what we need to change to add the same in "WixSetup.targets" file for creating server deployment scripts? Thanks. 

Coordinator
May 16, 2011 at 11:25 PM

What version of the Deployment Framework are you using?  I'm not sure what you mean.  The default implementation of DeployAppDefinition in BizTalkDeploymentFramework.targets already includes an Exec task followed by AddAppReference.  In any case, it sounds like this is unrelated to x64 vs. x86 if you did not do anything with respect to that.

When you are using the built-in AppsToReference ItemGroup, it must be defined before the <Import> element in your .btdfproj.  If the .targets file does not see it defined, then it will skip the AddAppReference task.  You can always print out the value along the way by including a task <Message Text="AppsToReference=@(AppsToReference)" />.

What is the output from your deployment script for the DeployAppDefinition target?

You should not try to solve this by modifying the Deployment Framework files, especially since this is long-standing and well-tested functionality.  Something else is going on here.

Thanks,
Tom

May 17, 2011 at 3:29 PM

Tom,

       We are currently using V5.0.25. We made it work today for server deployment as well. We are not modifying any deployment framework files. Instead, we use our own ".target" and ".WixSetup.targets" files for our projects. We just copied it from the original installation folder and modify it for our own needs. If this not a correct approach, please let us know what is the correct approach to do it. Further, please enlighten us on the below questions,

1. We are planning to move to the latest version V5.0.26. Do you have any upgradation document that we can follow? We just don't know what kind of challenges that we will face when we do the upgradation.

2. When we opened up the framework source code, we noticed that "AddAppReference" is usnig Explorer OM API named "Application" to do the reference. However, Explorer OM is not supported on 64-bit platform. We are just curious how those APIs are working fine on 64-bit platform. Here is the MSDN link for your reference...

http://msdn.microsoft.com/en-us/library/aa559050(v=bts.20).aspx

Overall this is a great framework and we are really happy with it. Thanks a lot for your quick responses always....

-Ashok

 

Coordinator
May 17, 2011 at 4:10 PM

Hi Ashok,

Thanks!  To address your questions:

1) You should not need to make any changes in order to upgrade.  You can see exactly what changed here.  It's a couple of small new features and a number of bug fixes.

2) ExplorerOM is not supported from 64-bit processes.  It is supported on x64 platforms.  As we discussed earlier, you must always run the 32-bit version of MSBuild.exe on Windows x64.

There are many extensibility points built into the Framework to do extra work during deploys or undeploys.  In your .btdfproj, you may redefine (after the <Import> line) any target defined in the base .targets files simply by re-declaring it.  If you want to plug in new behavior, you can do so at various execution points by overriding the targets CustomPreInitialize, CustomPostInitialize, CustomDeployTarget, CustomUndeployTarget, etc.  You'll see the full list grouped together in BizTalkDeploymentFramework.targets.  By using these extensibility points and, in the rare cases where it's necessary, overriding the implementation of a built-in target's implementation in your .btdfproj, you should not need to modify or maintain separate copies of the base .targets files.  Does that make sense and accomplish what you are thinking?

As to your application reference issue, if you could please be absolutely certain that the 32-bit MSBuild.exe is executing in Visual Studio, then we can rule that out.

I'd also recommend that you take a fully working sample, like the included HelloWorld sample app, and try deploying it.  If that works OK, then try adding <AppsToReference> to the sample's .btdfproj and try again.

Thanks,
Tom

May 18, 2011 at 2:36 PM

Thanks Tom. We would try to accomplish everything just within the .btdfproj project without taking the copy of .target files in our next project. We are not able to see where we can find the path for MSBuild.exe. I have checked the output log entires and i am not seeing any path on it. However, It looks that everything is working fine now. Further, we are planning to move our scripts to the latest version V5.0.26 soon. Can you let us know when would be the stable release for this version?

Thanks,

Ashok

 

 

Coordinator
May 18, 2011 at 3:17 PM

Hi Ashok,

One thing you can do on Windows 7 or Server 2008 (R2 only?) is open Task Manager, run the deploy, find the running MSBuild.exe process in the Task Manager process list, right-click it and hit Properties.  That will show the path.  You can also just look next to the EXE name in the process list and see if it has "*32" next to the name.  In our case, it should always say "*32".

I am very confident in the 5.0.26 release, so there is no need to wait.  As far as a final 5.0 release, I'm not sure when that will happen (depends when I can find personal time to finish it).

Thanks,
Tom

May 18, 2011 at 3:39 PM

Great...I am able to see the 32-bit MSBuild.exe on the task manager. I become a fan of this framework now. I really appreciate all your great work. Thanks a lot for all your help.

-Ashok

 

Coordinator
May 19, 2011 at 6:33 AM

Thanks, and you're very welcome!  Sounds like the x86/x64 thing was probably not the issue after all, but I'm not sure that we found a root cause for your app reference issue.  Hopefully you can try that out again on your next project.

Thanks,
Tom