BizTalk 2013 R2: Error in receive pipeline - biztalk

Facing an issue after deployment of BizTalk solution on another server.
Error is highlighted below:-
There was a failure executing the receive pipeline:
"BTAHL72XPipelines.BTAHL72XReceivePipeline, BTAHL72XPipelines,
Version=1.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35"
Source: "BTAHL7 2.X Disassembler" Receive Port:
"HL7_25_ADT_A02_ReceivePort" URI: "******Some Location*******"
Reason: Field not found:
'Microsoft.Solutions.BTAHL7.Pipelines.MessageUtils.VersionforAck24'.
PS: I have already installed BizTalk 2013 R2 with HL7 Accelerator R2 two times on server.

It looks to me a installation issue, I have been running BizTalk 2013 R2 with HL7 Accelerator without any issues. Some suggestions
Most likely you have an old version of Microsoft.Solutions.BTAHL7.PipelineCommon.dll (possibly 2010 version). Make sure its version is 3.11.158.0. This assembly can be found in "\Program Files (x86)\Microsoft BizTalk 2013 R2 Accelerator for HL7\Bin" folder.
Uninstall HL7 Accelerator and Install it again, make sure you use 2013 R2 iso file

Is the assembly Microsoft.Solutions.BTAHL7.PipelineMessageCore deployed? Check under All Artifacts->Resources. Try redeploying it if it's in there.
Also take a look at the schema from that assembly under All Artifacts->Schemas and make sure it has the node. If it doesn't, you definitely have to redeploy from the original installation version, or at least undo any modifications that hav ebeen made to rename/remove that node.

Earlier we were using window server 2012.
In order to fix this issue, we did installation for window server 2012 R2,
Sql server 2014, VS 2013 and Framework 4.5.
Thanks all for helping out to resolve this issue.

I don't clearlyunderstand if it is a custom pipeline but if it is then you should copy your custom pipeline component to path
C:\Program Files (x86)\Microsoft BizTalk Server 2013 R2\Pipeline Components
if you are on development environment and tired of copying dll then a good way is:
Your dll mus must be deployed in GAC. Then a simpler way to do that is using gacutil.exe to deploy it. By the help of Visual Studio you can achieve this by post build event
"C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\bin\NETFX 4.0 Tools\gacutil.exe" /i $(TargetPath)
After that you don't have to copy any dll but in production this may leads you forgetting to copy be careful.

Related

csc.exe including two versions of GAC_MSIL\Microsoft.ReportViewer.WebForms - when running under IIS

I'm using Visual Studio Professional 2012 on a Windows Server 2008 R2. When I run my MVC web application under IIS, I get the error:
Compiler Error Message: CS0433: The type 'Microsoft.Reporting.WebForms.ReportViewer' exists in both
'c:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.WebForms\11.0.0.0__89845dcd8080cc91\Microsoft.ReportViewer.WebForms.DLL' and
'c:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.WebForms\10.0.0.0__b03f5f7f11d50a3a\Microsoft.ReportViewer.WebForms.dll'
After hours trying to resolve this, I discovered that when I "use Visual Studio Development Server" it works. This is good, but I'd like to get it working with IIS too.
Under IIS, the "detailed compiler output" includes:
c:\windows\system32\inetsrv> "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe" /t:library /utf8output ...
/R:"C:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.Common\10.0.0.0__b03f5f7f11d50a3a\Microsoft.ReportViewer.Common.dll" ...
/R:"C:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.WebForms\11.0.0.0__89845dcd8080cc91\Microsoft.ReportViewer.WebForms.dll" ...
/R:"C:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.WebForms\10.0.0.0__b03f5f7f11d50a3a\Microsoft.ReportViewer.WebForms.dll" ...
Under the VS Development Server (when I add a dummy error to my view), the only reference to ReportViewer is:
C:\Program Files (x86)\Common Files\Microsoft Shared\DevServer\11.0> "C:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe" /t:library /utf8output ...
/R:"C:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.WebForms\11.0.0.0__89845dcd8080cc91\Microsoft.ReportViewer.WebForms.dll" ...
I've tried several things to try to get it working under IIS. There aren't any references to the 10.0.0.0 version of ReportViewer in my solution. I did a clean and rebuild. In IIS, the default web site did have a handler mapping referencing an older version of ReportViewer, which I removed. (I also tried adding a new handler mapping - no version specified - but that didn't work so I removed it.)
I tried the qualifyAssembly web.config node, as per The type 'Microsoft.Reporting.WebForms.ReportViewer' exists in both
And as per MSBuild Using Wrong Version of Assembly to Compile RDLC File I tried determining what VisualStudioVersion my build is using and even editing Microsoft.ReportingServices.targets (I put it back to what it was). This is the part that was getting to be over my head and I didn't want to mess anything up. Any ideas would be much appreciated.

BizTalk 2013 R2 installation

While installing BizTalk Server 2013 R2, when I try to check the component "Developer tools & SDK" it appears as an unavailable. I get the message "At least one of the requirements for this option is not installed or it doesn't met"
Could you please tell me why this option is unavailable? Do I need to install any other component before?
I am following the steps that I found at BizTalk 2013 Installation and Configuration – Install and Configure BizTalk Server 2013 (Part 9)
Ok here are all your possible installation scenarios :
You are installing BizTalk Server (whatever version) to make a Build Server =>Then yes you need Visual Studio to be able to install Developer tools & SDK, those packages contains MSBuild & other stuff that enable you to build & deploy an app
You are installing BizTalk Server as a "real" Server (Prod, Integration...) => You don't need developer tools & SDK
You are installing BizTalk Server on a Dev Machine => you are supposed to already have a Visual Studio installed
BizTalk 2013 /2013 R2 Project Templates with Visual Studio 2015
Yes, the Setup of the BizTalk 2013 requires for the feature 'Developer tools & SDK' per default Visual Studio 2012, and the Setup of BizTalk 2013 R2 Visual Studio 2013, otherwise the feature is disabled.
Frustrated with this fact (at work we have now upgraded to VS2015), I now find a way to install the templates under VS 2015 and without an installation of VS2012/ 2013 at the system.
Tool required: Orca to modify the msi.
Files to modify are located in subdir MSI of the BTServer dir of the extracted ISO (make a backup of these files!)
Installations to modify:
Microsoft BizTalk Server.msi and
Microsoft BizTalk Server64.msi
Modifications:
AppSearch-Table: Drop Row for the property 'CSHARP_INSTALLED'
Properties-Table: Add Row, property Name = 'CSHARP_INSTALLED', Value = 'True'
Properties-Table: Set the value of the property 'TargetVsVersion' to '14.0'
Do this for both MSI's, save.
Now, the Prerequirement VS 2012/ 2013 from the files
Setup.xml and
Setup_64.xml must be removed.
Simple remove the entry
<RequiredComponent Name="VS2012"/> or
<RequiredComponent Name="VS2013"/>
from the node
<Feature Name="Development">
DONE!
---EDIT
If someone has a valid RegKey to check if VS215 is installed, the Check in the Setup.xml can rewritten to this. This would be nice and valid
One valid modified Search for a Visual Studio 2015 installation could be:
<!-- language: lang-xml -->
<PlatformComponent _locAttrData="DisplayName" _locID="25" Name="VS2015" DisplayName="Microsoft Visual Studio 2015">
<Detection Type="RegDWORD">
<DetectKey Root="HKLM" Key="SOFTWARE\Microsoft\VisualStudio\14.0\Setup\Visual Studio 2015 Prerequisites" Value="InstallSuccess" ValueData="1"/>
</Detection>
Visual Studio 2013 is a software requirement for BizTalk Server 2013 R2 Developer Tools and SDK.
More info: Hardware and Software Requirements for BizTalk Server 2013 and 2013 R2

v11.0\WebApplications\Microsoft.WebApplication.targets was not found when file actually references v10

First some background. At the end of 2012 we migrated our vs2008 solution to vs2010 but we still target .NET 3.5. (I know nothing but the latest and greatest here!)
We hadn't had any issues with this setup until a few weeks ago when people started getting these errors:
"foo.csproj" (Rebuild target) (16:5) ->
C:\...\foo.csproj(142,3): error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
The interesting thing is that if you look at the project file it references v10 which makes sense because we don't use Visual Studio 2012.
This error hit several of us at once and even on older code branches that haven't changed in months.
I suspect some update got pushed onto our machines that confused things but I don't know what to do about it.
The short term solution has been to install VS 2012 and not use it but I'm hoping for something a little cleaner than that.
I ran into the same issue with Visual Studio 2013. It turns out that I was using the old version of MSBuild--the one that ships with the .NET Framework--from the command line. Microsoft is now releasing MSBuild as part of Visual Studio itself and also as a separate installer (http://blogs.msdn.com/b/visualstudio/archive/2013/07/24/msbuild-is-now-part-of-visual-studio.aspx).
The solution was to use the new version of MSBuild.exe located in C:\Program Files (x86)\MSBuild\12.0\Bin. Once I did that, all the targets errors disappeared.
EDIT 1
As mentioned in the comments, each new version of MSBuild brings with it a new directory. For Visual Studio 2015, use C:\Program Files (x86)\MSBuild\14.0\Bin.
EDIT 2
As mentioned in the comments, for Visual Studio 2017, use C:\Program Files (x86)\Microsoft Visual Studio\2017\<Edition>\MSBuild\15.0\Bin\MSBuild.exe.
If you have a build server that does not have VS2012 installed, you can fix this by
a) installing the MSBuild.Microsoft.VisualStudio.Web.targets package to your solution, and
b) replacing this line in the .csproj file:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
With this line pointing to the nuget package
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath\WebApplications\Microsoft.WebApplication.targets" Condition="true" />
EDIT
As #joedragons points out the version in the updated line should match the nuget package version, i.e. replace targets.11.0.2.1 with targets.x.x.x.x for the current version.
A simple solution to this problem:
Go to the following path:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio
You will see the latest version V10.0, v11.0, v12.0 depending on your Visual Studio 2010, 2012 or 2013 install.
Copy WebApplications folder from either of latest version directory and paste to other.
Your issues should be resolved.
I've found that installing the free Visual Studio 2012 Shell (Isolated) installs the WebApplications v11 MSBuild files. Lighter than a full install of Visual Studio 2012 and no licensing concerns.
Wow. We just saw the same thing happen on our build machine. We use VS2010 and target .NET 4.0. Our project files explicitly import the v10.0 version of these targets. With no changes to the code, yesterday the build was fine and today it's failing with a complaint about a missing v11.0 version. The .NET Framework 4.5.1 got installed/updated last night on this build machine as an automatic update. We're going to force v10.0 with the parameter (or env. variable), but this certainly took us by surprise...
UPDATE: What's even more weird, is that it seems to be the case that today's version of msbuild seems to be using the first line of the sln file to determine which VisualStudioVersion to use by default, whereas yesterday's version did not:
Format Version 12.00
We tested manually changing this to 11.00 and the build started working again.
In our case, even though we're targeting and building everything for 2010/4.0, some devs have been getting ready for VS2012 (since MS claimed that the project files are compatible), and this particular solution was last saved (months ago) in VS2012. Before today, that wasn't causing a problem.
I had the same issue. Fixed by going through above listed solutions. The issue is caused because appropriate version of Visual Studio Tools (BuildTools) is not available on the Build server. As rightly pointed above, this can be resolved by installing BuildTools but is not the option in my case.
Here is another alternative - use Nuget
Install-Package MSBuild.Microsoft.VisualStudio.Web.targets -Version 14.0.0.3
Identify the start up project and Install the web.targets based on the version of Visual studio being used.
The following files will be modified which includes the required changes
In packages.config:
<package id="MSBuild.Microsoft.VisualStudio.Web.targets" version="14.0.0.3" targetFramework="net45" />
In .csproj:
<Import Project="..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props" Condition="Exists('..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.14.0.0.3\build\MSBuild.Microsoft.VisualStudio.Web.targets.props')" />
Hope this helps!!! Good Luck,
Cheers,
Hack, but solved it by copying:
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications*.*
to
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\WebApplications*.*
I got this error in the end of November without making any changes to either the configuration of my TeamCity installation or MSBuild installation or the source code. On my build server Visual Studio isn't even installed, and the change from VS2010 to VS2012 was made in the end of August without any problems at the time.
My MSBuild version is 4.0.30319.18408, my build server is a Windows Server 2008 R2 SP1 with TeamCity v6.5.3.
I solved the issued by simply copying the v11-folder from another build server which was unaffected.
My guess is that this could have happened in two ways:
Something was updated which triggered a deletion of the v11-folder. Could it be a Windows Update to .NET or something?
Something was updated which changed my TeamCity/MSBuild configuration from using v10 to v11 and the builds stop working as the v11 never existed.
I've got a update to .NET Framework 4.5.1 on December 3rd, could that be the reason?
Brgds
Jonas
I've recently got stuck with the same problem. And my conclusion is that every version of VS (v10, v11, v12) changes path of build variable, like MSBuildBinPath.
So specifying exact version of VS isn't a hack, because you might not even have appropriate version of files installed. So intead you'd better specify a parameter and use targets that exist on you machine.
In some rare cases you might need to install specific version of VS and Web Deploy package. In my case just version was enough to solve problem.
You can add the VisualStudioVersion property like this:
<ItemGroup>
<ProjectToBuild Include="$(MSBuildProjectDirectory)\..\MySolution.sln">
<Properties>Configuration=$(BuildConfiguration);WarningLevel=0;VisualStudioVersion=12.0</Properties>
</ProjectToBuild>
</ItemGroup>
<MSBuild Projects="#(ProjectToBuild)" Targets="Rebuild"/>
As I was searching how to solve this one, almost everyone recommended either to copy the missing MSBUILD folder or install some SDK of some version.
Luckily, I've found this awesomely helpful post by Donovan Brown :
http://donovanbrown.com/post/So-sick-of-MicrosoftWebApplicationtargets-was-not-found-build-errors!
In a nutshell, the idea is to configure the VisualStudio version your build should use in your Build Definition:
Right Click -> "Edit Build Definition..."
Go to "Procss" -> "3. Advanced"
and set "MSBuild Arguments" with
/p:VisualStudioVersion=12.0

BizTalk 2009 projects not playing well with TFS 2010 beta 2 automated build?

I was wondering if anybody is using TFS 2010 beta 2 build server to build BizTalk 2009 projects created in VS 2008?
I created new BizTalk project in VS 2008 adding simple schema with promoted property. Then I created new build definition from VS 2008 Team Explorer and queued up new build on our TFS 2010 build server...
I'm getting compilation errors due to the conflicts in .NET Framework versions. Here is a snippet from compilation log:
CoreCompile:
C:\Windows\Microsoft.NET\Framework\v3.5\Csc.exe /noconfig /nowarn:1701,1702 /errorreport:prompt /warn:4 /define:TRACE /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Configuration.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll /reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Xml.dll /reference:"C:\Program Files\Microsoft BizTalk Server 2009\Microsoft.XLANGs.RuntimeTypes.dll" /reference:"C:\Program Files\Microsoft BizTalk Server 2009\Microsoft.BizTalk.Interop.Agent.dll" /reference:"C:\Program Files\Microsoft BizTalk Server 2009\Microsoft.BizTalk.Messaging.dll" /reference:"C:\Program Files\Microsoft BizTalk Server 2009\Microsoft.XLANGs.Engine.dll" /reference:"C:\Program Files\Microsoft BizTalk Server 2009\Microsoft.XLANGs.BizTalk.Engine.dll" /reference:"C:\Program Files\Common Files\Microsoft BizTalk\Microsoft.RuleEngine.dll" /reference:"C:\Program Files\Microsoft BizTalk Server 2009\Microsoft.XLANGs.BizTalk.ProcessInterface.dll" /reference:C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.dll /reference:C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.Xml.dll /reference:C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.Data.dll /reference:C:\Windows\Microsoft.NET\Framework\v4.0.21006\System.Web.Services.dll /reference:"C:\Program Files\Common Files\Microsoft BizTalk\Microsoft.BizTalk.TOM.dll" /debug:pdbonly /keyfile:somekey.snk /optimize+ /out:obj\Release\TestSchemas.dll /target:library /warnaserror- Properties\AssemblyInfo.cs "C:\Builds\2\Test Project\Test Build\Sources\TestBizTalkApp\TestSchemas\SomeSchema.xsd.cs" "C:\Builds\2\Test Project\Test Build\Sources\TestBizTalkApp\TestSchemas\PropertySchema.xsd.cs"
CSC : warning CS1685: The predefined type 'System.Runtime.InteropServices.DefaultParameterValueAttribute' is defined in multiple assemblies in the global alias; using definition from 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.dll' [C:\Builds\2\Test Project\Test Build\Sources\TestBizTalkApp\TestSchemas\TestSchemas.btproj]
PropertySchema.xsd.cs(64,35): error CS0433: The type 'System.Xml.XmlQualifiedName' exists in both 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.XML.dll' and 'c:\Windows\Microsoft.NET\Framework\v4.0.21006\System.XML.dll' [C:\Builds\2\Test Project\Test Build\Sources\TestBizTalkApp\TestSchemas\TestSchemas.btproj]
PropertySchema.xsd.cs(72,36): error CS0433: The type 'System.Xml.XmlQualifiedName' exists in both 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.XML.dll' and 'c:\Windows\Microsoft.NET\Framework\v4.0.21006\System.XML.dll' [C:\Builds\2\Test Project\Test Build\Sources\TestBizTalkApp\TestSchemas\TestSchemas.btproj]
Done Building Project "C:\Builds\2\Test Project\Test Build\Sources\TestBizTalkApp\TestSchemas\TestSchemas.btproj" (default targets) -- FAILED.
Done Building Project "C:\Builds\2\Test Project\Test Build\Sources\TestBizTalkApp\TestBizTalkApp.sln" (default targets) -- FAILED.
Done Building Project "C:\Builds\2\Test Project\Test Build\BuildType\TFSBuild.proj" (CompileSolution target(s)) -- FAILED.
Done Building Project "C:\Builds\2\Test Project\Test Build\BuildType\TFSBuild.proj" (CompileConfiguration target(s)) -- FAILED.
Done Building Project "C:\Builds\2\Test Project\Test Build\BuildType\TFSBuild.proj" (CoreCompile target(s)) -- FAILED.
As you can see, there are references to the same assemblies for two different framework versions (2.0 and 4.0) which is causing conflicts.
Our setup is: Win2008 box with BizTalk 2009, VS 2008 SP1 and we installed TFS 2010 beta 2 build service on the same box and configured to run only as an build agent. Then we've got another Win2008 box with TFS 2010 beta 2 which is configured as a source control and build server with only a build controller set-up.
Any help on how to get rid of the references to framework 4.0 from build would be much appreciated. Thanks!
We installed final version of TFS 2010 but had the same issue with conflicting assemblies. It turns out there is a bug in BizTalk build task. Details and workaround can be found here.
I submitted a bug report to Microsoft and here is reply:
We had a previous report around building BizTalk projects with TFS 2010 and I'm happy to say that it's been resolved for the release candidate. Thanks for reporting the issue.
I guess the only option now is to wait for RC and hope they really fixed that issue.

Using Visual Studio 2008 Web Deployment projects - getting an error finding aspnet_merge.exe

I recently upgraded a VS2005 web deployment project to VS2008 - and now I get the following error when building:
The specified task executable location "bin\aspnet_merge.exe" is invalid.
Here is the source of the error (from the web deployment targets file):
<Target Name="AspNetMerge" Condition="'$(UseMerge)' == 'true'" DependsOnTargets="$(MergeDependsOn)">
<AspNetMerge
ExePath="$(FrameworkSDKDir)bin"
ApplicationPath="$(TempBuildDir)"
KeyFile="$(_FullKeyFile)"
DelaySign="$(DelaySign)"
Prefix="$(AssemblyPrefixName)"
SingleAssemblyName="$(SingleAssemblyName)"
Debug="$(DebugSymbols)"
Nologo="$(NoLogo)"
ContentAssemblyName="$(ContentAssemblyName)"
ErrorStack="$(ErrorStack)"
RemoveCompiledFiles="$(DeleteAppCodeCompiledFiles)"
CopyAttributes="$(CopyAssemblyAttributes)"
AssemblyInfo="$(AssemblyInfoDll)"
MergeXmlDocs="$(MergeXmlDocs)"
ErrorLogFile="$(MergeErrorLogFile)"
/>
What is the solution to this problem?
Note - I also created a web deployment project from scratch in VS2008 and got the same error.
Apparently aspnet_merge.exe (and all the other SDK tools) are NOT packaged in Visual Studio 2008. Visual Studio 2005 packaged these tools as part of its installation.
The place to get this is an installation of the Windows 2008 SDK (latest download).
Windows 7/Windows 2008 R2 SDK: here
The solution is to install the Windows SDK and make sure you set FrameworkSDKDir as an environment variable before starting the IDE. Batch command to set this variable:
SET FrameworkSDKDir="C:\Program Files\Microsoft SDKs\Windows\v6.1"
NOTE: You will need to modify to point to where you installed the SDK if not in the default location.
Now VS2008 will know where to find aspnet_merge.exe.
I just ran into this same problem trying to use MSBuild to build my web application on a server. I downloaded the "web" version of the SDK because the setup is only 500KB and it prompts you for which components to install and only downloads and installs the ones you choose. I unchecked everything except for ".NET Development Tools". It then downloaded and installed about 250MB worth of stuff, including aspnet_merge.exe and sgen.exe
You can download the winsdk_web.exe setup for Win 7 and .NET 3.5 SP1 here.

Resources