We have a BizTalk Pipeline which uses a custom pipeline component. There are various assembly versions of the pipeline component available and we wanted to know the version with which this pipeline was compiled with.
We loaded the pipeline in the resources (Add as BizTalk Assemblies and Resources, tried both ), but the dependencies tab does not show any component dependencies.
Tried with other Pipeline Projects as well to verify if this behaviour is exhibited by all other pipelines as well. And found it be true.
Is this an expected behaviour or am I missing something.
Version - BizTalk Server 2013 / Windows Server 2012
The same behaviour occurs in BizTalk 2013 R2.
It only shows which Send Ports or Receive Ports use the Pipeline, but the Using: section is blank and does not show you what Pipeline Components are referenced.
You can go the the Send & Receive Ports themselves and see the component names there, but that will not show you what version it is using.
If your different versions of the Pipeline Component have the same Strong Name Key and only differ in the assembly version number then it will either use the latest version from the GAC, or if not found in the GAC it will use the version in the Pipeline Components folder.
Also see this blog Find BizTalk Pipeline Component References
Related
I am using BizTalk 2016 and I want to enable build from VSTS.
Build fails because it asks for some *.json files.
After some investigation I reached the conclusion that I have to create
a btaproj file. Add a BizTalk Server application to Visual Studio Team Services
I installed Feature Pack 1 but there is no option for BizTalk Application project.
How can I create a btaproj file?
Did you select .NET Framework 4.6.1 in create new project dialog?
fr step by step instructions, please follow https://www.codit.eu/blog/2017/05/02/bts-2016-feature-pack-i-continuous-deployment-walkthrough/
I used the steps described in usman-shaheen post
Then I had an error during building. In project's properties, under Build Events -> Post-build events there were some commands, probable written by VS. These commands were causing an error during building. If I was starting VS as admin, they were not causing any error and building was finished correctly. By removing these commands, agent could run and build my app.
This morning it was reported that our web app on our QA server was completely broken with the following error reported from Web.config:
Could not load file or assembly 'System.Web.Mvc, Version=5.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified
Remembering seeing a Windows Update that mentioned MVC, I did some digging and found lots of people reporting a recent Windows Update breaking MVC.
After much digging through those questions and our server, it seems that what's bitten us does not match what's in those other questions, but it does appear related. Here's what we think know:
Our app that is broken uses ASP.NET MVC 5.1
MVC was installed via NuGet
Our BuildServer and QA servers do NOT have MVC 5.1 installed (therefore, not GAC'd)
What we believe has broken caused the "bad build" to be created:
A patch for MVC 5.1 was installed on the BuildServer via Windows Update despite not having MVC 5.1 installed in the GAC
The patch has put the "updated" version of MVC 5.1 in the GAC
CopyLocal=true is ignored when a DLL is in the GAC; therefore since the patch, this means that builds of our app from the BuildServer no longer have System.Web.MVC in the output folder
Since System.Web.MVC is not in the GAC on our QA servers (they have not yet been patched), the application now fails, because System.Web.MVC cannot be found
Assuming the behavior described above is correct, this means that any time MS service a NuGet DLL via Windows Update that we do not have in the GAC, our BuildServer will start producing incomplete builds (missing out those DLLs that have been injected into the GAC).
Upgrading to MVC 5.2 solves this issue (likely because it wasn't patched, and was therefore not injected into the GAC); the DLL is now copied to the output folder. There are no changes in the diff that upgraded to 5.2.2 except for version number changes (there's specifically no <Private> node been added/edited).
We do not wish to start GACing everything, nor creating manual build steps to copy all of our DLLs into the bin folder just in case MS patches them.
So, what can we change today to ensure we don't ever end up with out BuildServer silently producing back bad builds if MS patch other DLLs in the future?
A patch for MVC 5.1 was installed on the BuildServer via Windows Update despite not having MVC 5.1 installed in the GAC
Yes, this behavior is actually by design. See http://blogs.msdn.com/b/dotnet/archive/2014/01/22/net-4-5-1-supports-microsoft-security-updates-for-net-nuget-libraries.aspx.
The patch has put the "updated" version of MVC 5.1 in the GAC
Yes, that's correct; it's how the patch gets the updated code to run instead of the old code. See https://technet.microsoft.com/en-us/library/security/ms14-059.
CopyLocal=true is ignored when a DLL is in the GAC; therefore since the patch, this means that builds of our app from the BuildServer no longer have System.Web.MVC in the output folder
Not exactly. What actually happens is a project that previously was CopyLocal=true gets switched to CopyLocal=false. CopyLocal can be set in one of two ways: 1) If there's an explicit <Private>True</Private> setting in the .csproj file, or 2) By default, if no such setting exists (GAC'd assemblies do not CopyLocal by default; other assemblies do).
So what appears to have happened in this case is that your project file didn't have this setting in the csproj file. As a result, the GUI showed the setting based on the evaluated default value before the patch (CopyLocal = true) but then after the patch was installed, the GUI will now show the new default value for a GAC'd assembly (CopyLocal = false).
Since System.Web.MVC is not in the GAC on our QA servers (they have not yet been patched), the application now fails, because System.Web.MVC cannot be found
That's correct.
Assuming the behavior described above is correct, this means that any time MS service a NuGet DLL via Windows Update that we do not have in the GAC, our BuildServer will start producing incomplete builds (missing out those DLLs that have been injected into the GAC).
For any .csproj reference without an explicit <Private>True</Private> setting, that is correct. Also, note the using NuGet to update your MVC reference can remove this setting even if it was previously present. See http://nuget.codeplex.com/workitem/4344.
Upgrading to MVC 5.2 solves this issue (likely because it wasn't patched, and was therefore not injected into the GAC); the DLL is now copied to the output folder. There are no changes in the diff that upgraded to 5.2.2 except for version number changes (there's specifically no node been added/edited).
That's correct. Since MVC 5.2 is not GAC'd, even without an explicit <Private>True</Private> setting, the default value of this non-GAC'd assembly will be CopyLocal=true.
We do not wish to start GACing everything, nor creating manual build steps to copy all of our DLLs into the bin folder just in case MS patches them.
So, what can we change today to ensure we don't ever end up with out BuildServer silently producing back bad builds if MS patch other DLLs in the future?
The best you can do today is:
Put explicit <Private>True</Private> settings in your .csproj file for all your NuGet package assembly references.
Until NuGet bug #4344 is fixed, any time you use NuGet to update a package reference, go back into your .csproj file and re-add the explicit <Private>True</Private> setting.
I believe this issue is addressed in the .Net Web development tools and UI blog here: link
I won't repeat the whole thing here, as the issue and resolution is explained pretty well at that link.
However just to repeat the key points, which should explain why this has happened:
As part of patch KB2994397 MVC 5.1 was added to the GAC.
There appears to be a NuGet bug that resets CopyLocal flag. (see link ) This means that when a machine with the above patch deploys to a non-patched machine it will break!
MVC 4 has had its assembly version number incremented by the same security update - MS14-059 (so the GAC version will NOT be used) This explains why the MVC 4 version still works - despite it being in the GAC.
I added a note about this issue in my blog:
Microsoft Asp.Net MVC Security Update MS14-059 broke my build!.
Your analysis of the problem is right on the money, by default the Copy Local flag is set to false when the assembly is in the GAC, manually setting it to true should fix this problem.
Upgrading to 5.2.2 is even better, you get the benefits of the new release in addition to the security fix.
I'm using Visual Studio 2013 and MvvmCross to create an Android application using Portable Class Libraries.
I notice in my first view model, CatalogViewModel, some code is highlighted as not referencing the correct assemblies or unable to be resolved (the code builds fine even with these issues).
Examining the .NET Portable Subset assembly in the Object Browser shows various System assemblies included (2.0.5.0 v2.0.50727 & v4.0.30319, 4.0.0.0, 5.0.5.0). Automatic binding redirection for assemblies in .NET Framework 4.5.1 can be enabled or disabled by adding this line to the .csproj file.
<AutoGenerateBindingRedirect>true</AutoGenerateBindingRedirect>
or
<AutoGenerateBindingRedirect>false</AutoGenerateBindingRedirect>
This seems to solve the referencing and redirection issues in the IDE. I haven't found any information about this manual modification to the Core project file in any of the MvvmCross info online I reviewed so I wanted to post a question here to see if anyone had some information or best practices.
No, you shouldn't need AutoGenerateBindingRedirect. This feature is intended to generate binding redirects for non-platform assemblies, such as NuGet packages. Platform assemblies should be unified automatically by Visual Studio / MSBuild.
Which seems to work, since you pointed out:
the code builds fine even with these issues
So this looks like a bug in ReSharper. The fact that adding AutoGenerateBindingRedirect fixes your ReSharper issues might be a side effect of something else.
I don't have access to an IIS server but I am told that the site is configured to run with version 1.1 of the .NET Framework. When I use Telerik JustDecompile I see the following.
The "NET 1" seems to suggest that the 2 dlls are compiled against version 1.1 of the FW. Does the "ANY" next to the website dll "GLSS" indicate that the site can run against any version ofthe .NET FW that is installed on the web server?
In preparation for an upgrade to 2.0, I have asked the web admins to change the site configuration to version 2.0 of the FW and I was surprised that the site, which I considered to be running 1.1 code, still worked. Should I be surprised?
Is this just a simple example of backward compatability and that the site could be configured to use any version of the framework provided that it was equal to or higher than the version that the code was compiled to use?
when I look at the property pages for the projects in the solution, I was surprised that, for the website project only, I was unable to locate where one sets the version of the FW which you want to compile against. I was able to locate it for the referenced projects.
Can you help me better understand the relationship between the version of teh FW that a site is configured and the versions that the assemblies are compiled against?
You should not be surprised, .NET was always backward compatible in a sense that assemblies compiled against a version of the runtime are supposed to run against a newer version of the runtime.
There are of course subtle issues where things are not backward compatible, starting from subtle semantic differences and ending with changes at the object contract level (where the expected method/class just does not exists anymore) but in general these problems depend on the complexity of your application. It is safe to assume that simple applications should just work with no issues.
The number of the runtime the assembly has been complied against is a part of the assembly's metadata, it can be read with reflection. Thus, at runtime, you have at least two possible versions of the runtime - the one the assembly has been compiled against and the current version of the runtime which executes your code.
Is a (full) BizTalk 2010 installation needed to let a build server (TFS2010) build BizTalk 2010 solutions/projects ?
As per my knowledge, BizTalk 2010 installation is not required. You only need below components.
Project Build Component available under Additional Software(to build the project)
Developer Tools and SDK (to run tests)
I did find an apparent exception where if you deal with anything EDI related, it seems to require the full BizTalk install(not configuration). I wanted to add this footnote for people experiencing compile errors where local compile works fine.