I'm trying to deploy a new version of a BizTalk application that contains common orchestrations for several applications (about 20 or so). The new version contains a new orchestration that will be used by several new applications.
When I try importing the msi for the new version I get an error saying:
"Cannot update assembly "[assembly_name]" because it is used by assemblies which are not in the set of assemblies to update.
To update the assembly, remove the following assemblies: "[dependant_assembly1]
[dependant_assembly2]
..."
The BizTalk server is not accessible from a development environment so the application must be updated using the BizTalk administration console. How do I import the updated application without having the remove and reinstall all 20 or so dependant applications?
Thanks
It sounds like you are deploying a new base application with the same version numbers as an existing, older version.
What works for us:
Every time you deploy a new version of your application, increment the version number (since the assemblies are GAC'ed, BTS supports side by side versioning). Any custom assemblies which are changed should also be versioned.
After deploying to your new Application to your local BizTalk, edit the resources to ensure that the correct (latest) versions of all referenced assemblies and bindings etc are up to date (remove old ones, add new ones).
Your common application will now contain both old and new versions of the assemblies. Newer versions of your 'client' applications will use the later version of your base / framework / common application.
Once all dependent applications have been upgraded, you can then remove the old version.
But the real solution seems to be to consider decoupling your applications more, e.g. by using messaging between the applications - this way, you can split out just the schemas as a common reference to the applications.
You can actually hack the deployment process on BT a little bit further than this, if you want to omit the versioning, depending on your access to the actual BT box. (Convince your sysadmin)
If you only have access to the deployment console, stop your dependent applications, remove their reference to the application you want to upgrade, and then deploy over the top, re-add your references and restart the dependent applications. You don't actually have to reinstall.This method is tedious and sucks but it will work. We do this because we have too much in our BT installs to further clutter them with multiple versions of the same app
Here is the hack. You'll need either access to the server (which I know you said you don't have) or the ability to install a service which can receive a dll and preform the below function for you. (I'm thinking you might convince someone to let you set this up) DISCLAIMER, this is not a supported solution and I claim no responsibilty blah blah blah
We do this all the time as we have WAY too many applications to do the first solution. You can slam your newly compiled DLL into the GAC. This NOT recommended by MSFT etc. but we use it in production on servers that have approx. 4000 dlls in the GAC and 1200 BT applications. You'll need to make sure that your metadata is identical i.e. you have the same version, key token etc. and you'll want to have some way of tracking your dlls outside the versioning system (we build a custom deployment infrastructure to do this). Finally once you have pushed your dlls into the GAC you'll need to restart your biztalk services. Make sure you don't have any suspended instances referencing the app you want to redeploy because they will prevent biztalk from pulling a new reference from the GAC when it restarts.
Finally it is important to note that this method will NOT work if your changes require changes in the MessageBox subscrition (things like changes in receive shape filters, correlations etc.) You will also be giving up some functionality in the orchestration debugger if you use this method to change the structure of orchs. The graphic will display the structure of the orchestration when last properly installed but your event list will be correct for the newest version. Finally, if you are replacing schema dlls you want to make doubly sure that you restart services as BT will cache schemas indefinitely.
Related
I am using Spring Source Tool Suite 2.8.1 to implement Spring applications.
I frequently get build errors because references are lost for no apparent reason. In Right-click project in Package Explorer->Properties->Java Build Path->Order and Export, I find projects sometimes are deselected. And often packages are gone in Right-click project in Package Explorer->Properties->Java Build Path->Deployment Assembly.
Having to reset these settings frequently is frustrating. Is there some way I can work around these problems?
I have tried to update STS to the latest version, but the upgrade process fails with incomprehensible error messages. I want to avoid a clean install because setting up the environment again would probably be a nightmare.
Now that I know this is a maven project and you are adding references yourself, this is making sense to me. STS 2.8.x was the last STS to ship with the legacy m2e (maven plugin for Eclipse). It did not recognize build path entries added manually (it likes to have complete control over the classpath). So, what is likely happening is that you are adding these classpath entries and then an update project operation gets kicked off automatically. This will have the effect of removing all of your extra classpath entries.
You are best off doing the following:
Updgrading STS
Or just upgrading your m2e component (you will have to first uninstall the old m2e, but this should be taken care of automatically from the discovery update page).
Or, just accept the fact that you can't manually change your classpath with the legacy m2e.
I have a solution with a fair few projects, 3 of them web-based (WCF in IIS / MVC site). When the solution builds, it dumps each of the components of this distributed system in a 'Build' folder. Running the 'configurator' part of the whole output will set up the system in the cloud automatically. It's very neat :) However, the Web Deploy Projects are a major pain. They "build" (i.e. deploy) every, single, time I build - even when no changes have been made to their respective projects.
Changed a single line of code? Look forward to waiting around a minute for the 3 web projects to redeploy.
[These projects are VERY straightforward at the moment - two have a single .svc and one .ashx file - the other is an MVC app with ~5 views]
I realise I can change solution configurations to not 'build' them, but I've been doing that and it's very easy to log on the next day and forget about it, and spend a couple of hours tracking down bugs in distributed systems due to something simply having not been built.
Why I use Web Deploy Projects? Well, because I need all pages + binaries from the web project. The build output for the project itself is the 'bin' folder, so no pages. The entire project folder? It has .cs, .csproj and other files I don't want included.
This will be building on build servers eventually, but it's local at the moment. But I want a quick way of getting the actual output files from the web project to my target folder. Any ideas?
Not sure if this will help in your situation, (plug for own project coming up), but I am working on a project to help ease IIS deployments:
https://github.com/twistedtwig/AutomatedDeployments
The idea being you can use config files for IIS (app Pool, applications and websites) to automate the creation and update of sites locally (dev machines) or remotely (test and production machines).
It is still a work in progress but is ready to be used in production systems.
using the package creation as a post build step might get you closer to what you want, (don't believe it includes all the extra files), but that would still build it each time, (although if code hasn't changed it should not rebuild unless you choose rebuild all projects).
In the end I created a utility/tool which, given a project file, XCOPYies the project folder for the web project to a target location, then looks in said project file and deletes anything that doesn't have Build Action set to Content. Very quick and effective.
I know it is still in RC but VS2012 does have a neat feature when doing publish that it detects the changes and publishes only those. Might be something a little deeper down in the build where it does an automatic publish too.
You can take a look to the Octopus project: http://octopusdeploy.com/
Deployment based on nuget packages.
I try to set up BAM for my BizTalk orchestrations. Everything is OK except the 2 orchestrations which are shown incorrectly in Tracking Profile Editor. For example, I've added an Expression shape with logging stuff to the end of every orchestrations, redeployed the app.
After that I opened all my orchestration one by one to ensure that all of them have that logging expression. For my surprise 2 of them was not changed. Moreover all of those orchestrations reside in one DLL so it cannot be caching issue.
When I went further inspecting the issue I found out that if I rename the type of an orchestration (e.g. "SET_DATACHANGES" --> "SET_DATACHANGES_") it will be shown in TPE with correct, most recent version.
Why does this happen?
The Tracking Profile Editor may be loading an incorrect version of the assembly containing the Orchestration components, either from the GAC or from the file system.
Did you deploy your BizTalk application from within Visual Studio? If so, did you also restart all relevant Host Instances?
Check that you don't have any previous versions of the compiled assembly sitting in a directory that the .Net assembly loader might include in its assembly resolution order.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.
What are the strategies for versioning of a web application/ website?
I notice that here in the Beta there is an svn revision number in the footer and that's ideal for an application that uses svn over one repository. But what if you use externals or a different source control application that versions separate files?
It seems easy for a Desktop app, but I can't seem to find a suitable way of versioning for an asp.net web application.
NB I'm not sure that I have been totally clear with my question.
What I want to know is how to build and auto increment a version number for an asp.net application.
I'm not interested in how to link it with svn.
I think what you are looking for is something like this: How to auto-increment assembly version using a custom MSBuild task. It's a little old but I think it will work.
For my big apps I just use a incrementing version number id (1.0, 1.1, ...) that i store in a comment of the main file (usually index.php).
For just websites I usually just have a revision number (1,2,3,...).
I have a tendency to stick with basic integers at first (1,2,3), moving onto rational numbers (2.1, 3.13) when things get bigger...
Tried using fruit at one point, that works well for a small office. Oh, the 'banana' release? looks over in the corner "yeah... that's getting pretty old now..."
Unfortunately, confusion started to set in when the development team grew, is it an Orange, or Mandarin, or Tangelo? It looks ok. What do you mean "rotten on the inside?"
... but in all honesty. Setup a separate repository as a master, development goes on in various repositories. For every scheduled release everything is checked into the master repository so that you can quickly roll back when something goes wrong.
(I'm assuming dev/test/production are all separate servers, and dev is never allowed to touch production or the master repository....)
I maintain a system of web applications with various components that live in separate SVN repos. To be able to version track the system as a whole, I have another SVN repo which contains all other repos as external references. It also contains install / setup script(s) to deploy the whole thing. With that setup, the SVN revision number of the "metarepository" could possibly be used for versioning the complete system.
In another case, I include the SVN revision via SVN keywords in a class file that serves no other purpose (to avoid the risk of keyword substitution breaking my code). The class in that file contains a string variable that is manipulated by SVN and parsed by a class method.
An inconvenience with both approaches is that the revision number is not automatically updated by changes in the externals (approach 1) or the rest of the code (approach 2).
During internal development, I'm using milestone numbers (M1, M2, M3...). After release, I'll probably just update dates ("the January 2009 update").