1

What BizTalk application, orchestration, schema, map changes are allowed to be not forced to import MSI via admin console but only install DLL in GAC?

Importing via console force to stop orchestrations and terminate instances but installing in GAC only require restart hosts of this application. So it will be sometimes convenient to not to stop everything on production environment.

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
Piotr Grudzień
  • 179
  • 3
  • 11
  • Please elaborate this with more details and a clearer description of what your problems are. Is that a generated MSI? What tool generates it, and what exactly does it do? – Stein Åsmul May 25 '18 at 11:42
  • @SteinÅsmul This is general question , my goal is to not to stop Application, Orchiestrations and terminate running instances of these applications – Piotr Grudzień May 30 '18 at 12:39

3 Answers3

3

Supported: Never.

You must always properly Deploy BizTalk applications. This nothing specific to BizTalk, all platforms have various deploy procedures.

During Development: Helper classes and internal changes to Schemas and Maps can often be slipstreamed in. Nothing that changes the signature of any artifact. Orchestrations can never be slipstreamed because the structure is used by the Tracking and can subtly change even with internal updates.

Johns-305
  • 10,908
  • 12
  • 21
  • When you say its never supported, you mean MS does not support it. Do you have any supporting document/link for it from MS – Vikas Bhardwaj May 30 '18 at 18:56
  • It's not supported in that it's not a tested procedure by Microsoft. That doesn't mean it won't work, just that it's not the correct procedure the product was developed and tested for. Still, don't it. Solve the real problem by developing a reliable deploy process. – Johns-305 May 30 '18 at 19:01
  • It works all the time, we have been using it. In a large environment with high message volume, stopping and redeploying is not an option. – Vikas Bhardwaj May 30 '18 at 19:10
  • @VikasBhardwaj I've run plenty of high volume apps and we've always done it correctly. Don't let convenience be an excuse. – Johns-305 May 30 '18 at 19:13
  • It's not about convenience. If it is supported by MS then I don't think it should be an issue. Also why to do extra steps of deployment when it is not needed. – Vikas Bhardwaj May 30 '18 at 19:18
2

There are big risks if you just GAC a DLL in Production without importing it into BizTalk.

  1. That if for your next deployment, you generate a backup MSI from Prod, it will contain the old DLL that is in the BizTalk database, and not the GACced version. This could mean that if you had to roll back using that MSI, you would lose your patch. We've experienced this when someone from another company had done a patch, and not only that, had not checked the change into source control, which was why we had to roll back in the first place as that change was not in the release package.

  2. Another scenario that after the deployment has to be rolled back is that you use the previous MSI (pre-patch) used for deployment previously and forget to re-apply the patch. Again this will cause you issues.

  3. If there is an issue and the schemas or maps in BizTalk don't match the GACced version, it makes diagnosing any issues a lot harder.

In summary don't do it, do proper deployment packages instead that are generated from a build server (so only what is in source control end up being deployed).

Dijkgraaf
  • 11,049
  • 17
  • 42
  • 54
  • 1
    If you use dev ops and build server to manage your MSIs, you won't ever need to generate an MSI from BizTalk environment. In my view, exporting MSI from BizTalk is not the right practice. – Vikas Bhardwaj May 30 '18 at 18:55
  • @VikasBhardwaj Yes I agree, using a build server to generate the build packages is best practice, then to roll back you just apply the previous one. However the backup MSI can still be useful in some cases, especially when others have not followed best practice and you need to determine what was changed. – Dijkgraaf May 30 '18 at 20:54
0

This is a very open question and answer largely depends on the change you r doing. Following is the list of items you should consider:

  1. Most of the time for minor changes to existing artifacts such as orchestration code/.net change, pipeline component, map or schema change can be done without importing MSI to BizTalk. In these cases just install MSI and restart host works fine.
  2. In some cases you can just add a specific resource rather than importing whole MSI. E.g if you are adding a new pipeline, as good as you have separate assembly for pipeline, you can add just pipeline assembly as resource to use new pipeline. Same way you can manage other artifacts. BizTalk also supports side by side deployment of assembly. The key to do this is to have artifacts in separate assemblies
  3. If any of above doesn’t work then consider full import.

Whatever option of deployment method you choose, you must test the same method in your dev, qa environments and catch any issue before doing it in prod.

Hope this help. There r other link on BizTalk deployment, you can refer to.

Vikas Bhardwaj
  • 1,455
  • 8
  • 10
  • Thanks, that was really helpful , We've done a lot minor changes and as You pointed at 1st point it worked, but as @Dijkgraaf pointed that is risky for the future deployment, I wont be doing that. – Piotr Grudzień May 30 '18 at 12:48