I am developing against a BizTalk 2009 environment. I am using BizTalk Deployment Framework (BTDF) to deploy my solution to the server. The problem I am facing is that when I tweak any aspect of my maps, the changes are not reflected in the BizTalk message body or output messages I use for testing. For instance, removing a link to a mapped element still shows the data being mapped from source to destination as if nothing has changed.
Between each deployment, the BTDF uninstalls the application, re-GAC's the assemblies, installs the application, and then bounces the host application. Ever so often BizTalk essentially catches up to my map version and it is working without issue until I make another tweak.
Is it possible that BizTalk is caching the map in a way that I cannot refresh?
Are you making your map changes in the BizTalk Mapper, or an XSLT?
Visual Studio does not recognise changes in an XSLT as requiring a re-build of the assembly. You would need to explicitly perform a "Rebuild" of the Map assembly in order to see these sort of mapping changes apply.
Hope this helps.
Are you building your dll's for deployment on your development machine?
Then remember that version of the map from GAC will take priority over your local map from visual studio.
I was many times cought by map dll taken from GAC instead of local folder.
Hope it helps
Related
The product I’m trying to create a package out of is a Web Application and a Database Project. This Package needs to be deployed to multiple IIS Web Sites which individually has their own application pool and bindings. In the end I would want the package to be built by a TFS Build Server into a .zip file which via msdeploy.exe somehow can be deployed to these web sites by settings the web site, application pool, binding and destination database in deploy time. It should create if items does not exists and update if they do.
I’ve been researching quite a lot on Web Deploy 3.0. Most of the stuff I find on the internet via google is about defining the package and publishing from within Visual Studio which is not exactly what I want because I want to be able to have control over the settings at deploy time.
So far I can create a package relatively simple via the Publish dialog in Visual Studio 2013. I can even add my SSDT project dacpac file to the package using the “Update Database” checkbox in the Publish window. But I think a lot of things happen behind the covers which doesn’t seem logic how to do manually.
Ultimately the questions I have right now which I hope someone can help me with is:
How do I define dbdacfx settings in deploy time when deploying a
package? (Ie. Target sql server, database, username and password.) Or
can I parametrize these settings somehow into a parameter.xml file?
Can I use the publish profile xml file from my SSDT project?
How do I make my package create a new web site if it does not exists?
I can only find information about creating applications under already
existing sites.
When and if I create a web site via the package, how do I define the
associated application pool? Like creating it if it doesn’t exist or
update it if the target framework is incorrect?
I’ve read about providers. For instance appPoolConfig provider but
how to utilize this at deploy time isn’t very clear to me – can
anyone elaborate or perhaps point to a source explaining it?
Is there any good books covering this area or perhaps even a better
alternative?
Once a week I get the new version of .net assembly which I need to deploy to our Axapta 2012 installation. I don't want to copy this dll to axapta client folder on each computer. So I am searching the way to deploy it to AOS and hope it will deploy on each client automatically.
I have found many solution (this is one of them), but all of them works only if I have the source code of this assembly. I don't have. And I can not to 'Add VS project to AOT' and deploy it using VS add-ins.
Is there any way to deploy .net assembly (as compiled DLL) from AOS to each client ?
If you cannot do it using the "Add VS projection to AOT" method, you can use the SysFileDeployment class. This is demonstrated in Joris DG his blogpost here.
On msdn the description of the SysFileDeploymentclass is as follows:
The SysFileDeployment class is used for deploying files from the server to the clients.
On msdn it is also explained how you need to do this.Basically all you need to do is extend this class and point to the files you need to deploy (in your case a dll). You will also have to change the build number of you solution to trigger the deployment.
You can also deploy dll's by adding them to the GAC, as demonstrated here:
Axilicious: AX2012 DLL Deployment and how AX binds DLL’s at runtime
To summarize main differences are:
Using the visual studio properties: it is deployed to a folder specific to that user (so a different folder for each user) at the moment it is needed
Using SysFileDeployment: it is copied to the client bin folder, a restart of the client is needed (possibly problems when on citrix/terminal services, like Joris suggests in the link you provided?)
GAC: DLL's are stored in the Global Assembly Cache and different versions are stored but you need to provide a mechanism of deploying them yourself
Personally I would try the SysFileDeployment method as it's the standard method MS provide. If you have trouble, you might receive support.
I need to create an installer program that will do install the following:
1. ASP.Net Website
2. Windows Forms application
with prerequisites(SQL Server 2008 express, .net Framework, IIS)
Both are under the same solution,
they share the same libraries and layers (data layer, business layer, etc)
So I'm facing a problem, because I think I should create 2 installers, one for the windows project and one for the web project, but this approach has a problem, it will create a data layer, a business layer and a common layer for each project, so if I want to update a layer, lets say I modified the data layer and I want to update it, I'll have to update both, so it occurred to me install those libraries in the GAC, but I don't know how to do it.
I also don't know if it's a good idea to create two installers, or if it's possible to create only one.
So basically the question is, do you know how to deal with:
shared libraries
Windows and web applications under the same solution
Prerequisites
IIS perms and configuration (pools, users, virtual directories)
all that inside the installer
We can buy installshield or similar if needed,
Thanks !!
I have worked on many projects with similar shared code block as you have neatly drawn out.
Experience has taught me to go with separate installers as you may want to update a single part of the client application, for instance, adding a couple of user option fields to the database and win forms application, which does not need an immediate rebuild of the web application.
With regards to installation, I would go with ClickOnce deployment (Click Once on MSDN) it's built in to Visual Studio, check out your project properties. It is easy to build, incorporates any pre-requisites you may have and can be installed from a central location. To update all your users, you simply click the publish button and they all have the latest version on next run.
I too would stay away from the GAC it is not worth the hassle.
Whether you should have one or two installers is really more a function of how your product will be used. If these two should always be installed together, a single installer seems to make more sense.
The MSI project in Visual Studio is very limited. VS2010 has InstallShield LE, but it's pretty cripped. I would try using LE, and buy InstallShield 2012 only if I had to (it's pricey).
As for the GAC, I would stay away unless your libraries will be shared across other products.
It will be hard to create a single installer for both program. You will need to customize the msi installer for the winform application and execute the webSite Installer packaged in the msi. Try first to do two installation system before combining them.
Currently, I'm maintaining an older ASP.NET website. In the solution, there exists 5 C# projects which build to assemblies as well as the development server's web directory. Normally, I do whatever work needs to be done (adding pages, making changes to existing projects, etc), build the projects (the current output path is my development server's wwwroot\bin\ directory) and if all is well, I open Windows Explorer and drag either .aspx or .dll files from the dev server to the production server. It's that last step that I'm wondering if there is a better way of doing. Does anyone have a different way of doing things where you don't have to leave Visual Studio to push updates?
You should add a Web Deployment Project, that´s (in my opinion) the easiest/best way to deploy a Asp.net app
Here´s an interesting article from the MSDN Magazine. http://msdn.microsoft.com/en-us/magazine/cc163448.aspx
ASP.NET Web Site Precompilation Overview would seem to be what you are wanting, yes?
Otherwise, there are web deployment projects for VS 2005 and web deployment projects for VS 2008 if you want a couple of alternatives depending on which version of Visual Studio you use.
How old is older? Are you using ASP.Net 1.0, 1.1, or 2.0, as those are what I'd consider older, but then I've been doing web development for over a decade.
You might want to consider creating a build script and a deployment script. You can look at using either Nant or MS Build, which are popular, or simply go with a batch file approach.
Some of the reasons I suggest going with scripts are:
1. You'll never forget to push that one file that you added
2. Either your build script or your deploy script should create a copy of all the artifacts need for deployment. This way, if you push out a bad build and need to roll back for whatever reason, guess what, you have a working copy tucked away somewhere.
3. Your scripts can run the installers (if you created a setup project) or they can simply copy out the files to the correct location, so that you don't have to have your dev box pointing to the right folder.
4. Sometimes you need to make changes to the configuration before you deploy... your scripts can also do this for you.
In general automating the whole process just makes it easier, faster and repeatable.
I have a DLL which is GAC'ced (c:\windows\assembly) which is being used by my Biztalk Application, for some requirement, I changed a function in that DLL and:
I uninstalled the old DLL which was in GAC (version 1.0.0.0)
I GAC'ced the newly built DLL into GAC (version 1.0.0.0)
I also restarted the BizTalk Host Instances.
But still the output seems to be from the old DLL's function. I am not getting the problem, why still I am getting the old output.
Can anybody help me?
Some tips that might be helpful:
(1) If you have multiple BizTalk servers in your group, be sure to update all of the servers!
Depending on your host instance configuration, your instance may run on any server the host instance is active on.
(2) Make sure you restart the correct biztalk host instance. This is often overlooked. Don't forget about the BizTalk Isolated Host! Perform a recycle of the specific IIS application pool if necessary. If you are unsure, perform an iisreset.exe
(3) To update a DLL in BizTalk it is often necessary to update it in the BizTalk database as well. For some changes it may work just updating the DLL in the GAC, but often I find that this is not enough (especially with orchestrations).
What you are describing here is correct. You should see the new DLL taking over. A couple things to check:
Did you recycle the correct host instances?
Did you recylce the host instances on all servers?
Did you veriiify the Create date on the GAC'd DLL to ensure the new one was installed?
Another issue might be based on what you changed in the Application. You can only Gac/Restart under particular circumstances. See this When can you just re-gac and re-start on Jon Flander's blog for reference.
If you want to be really sure that the correct assembly that has been GAC:ed, click "Run" and type "%systemroot%\assembly\gac" for .Net 1.1 or "%systemroot%\assembly\gac_msil" for > 2.0.
There you have the physical files for each version number to be checked (or overwrited).
It might help us support you if you let us know what part of BizTalk you are using the assembly, pipeline, functoid, schema etc.
Is that DLL used under a BizTalk process (BTSNTSvc.exe) or by an Isolated Host Instance?
If this DLL is used in a Receive Location which Receive Handler (Host) is Isolated, for example a SOAP Receive Location, you have to restart the Application pool from IIS and not the Host Instance.