MSBUILD with Different Template

J
Badge +8

I am about to investigate my question but wanted to know if anyone else knows the answer first.


 


In KB000188 - http://kb.k2workflow.com/articles/kb000188.aspx - it discusses how to running MSBUILD to deploy a project.  One of the properties is Environment.  In the example it just says "Production".  I assume that this will pick up the "Production" environment for the default template.  There is a good case that I will have multiple templates and they will not always use the default.  Does anyone know the correct syntax to specify which template and environment for the Environment property of MSBUILD?


 


Thanks,


Jason

6 replies

M
Badge +7

Hi Jason,


I haven't had any issues with different templates as during the 'create deployment package' process all the templates available from the development environment are copied into the MSBUILD file. If you specify an environment that has a different template on the command line, it *should* just work.


 MSBUILD myWorkflow /p: Environment=MyEnvironment


This could be an issue if you've generated your deployment package before a new envionment template was created, but you can easily add it into the MSBUILD script.


Martin

J
Badge +8

Martin,


DOH - you may me think and you are right.  So the msbuild will generate with the templateenvironment values that Visual Studio is currently running under.  When deploying, into a production environment it will take those values and push them into the StringTable.  Environments are not needed (I always forget that).  So if I have two templates, each with a production environment there should be no problem.


However I do see this an issue that needs to be resolved.  When working with different templates and environments in the K2 Workspace (and Visual Studio) you have the ability to create a template called Foo and another called Bar.  In each you can create development, quality assurance and production environment.  Why would I do that, I could eventually have to processes one called Foo and another called Bar.  I may want to use environment field names that are the same across processes but they have different values.  In the K2 workspace it will support that.  I can create a Field called "InfoPath Form Library" and when I set a default value between the two template/environments they are treated as different values.


This is not true on deployment!  So if I were to deploy with the production environment the name of the string table for the process will be production.  Now all of the processes that use the string table called production have shared values.  So process Foo and process Bar will use the same value for the "InfoPath Form Library" value which is going to be a problem.


I think the solution is to just manually rename the environment to template and environment (FooProduction or BarProduction) to avoid these sort of conflicts. 


It is also not an option to create a single Default template with distinct environment called FooProduction and BarProduction.  This is because processes using the same template all the environments fields even if they are not used.  I am big on being keeping things organized.  It can become confusing because I will have process specific fields for Foo and I do not want to see the Foo fields in Bar because it could give the impression that the Foo fields are required by Bar.


Hope this makes sense...


Thanks,
Jason

C
Badge +4

I don't understand how the scenario you are describing works period. Whenever I switch templates in VS (I don't do this normally, so maybe I am just doing it incorrectly), it switches the template for all my processes in the project, not just the process I am working on. Maybe it was just the process I tried it on because that was doing IPC calls and stuff and it didn't like differing templates.


To support the scenario you describe, you can just use one single template and then modify the string table for the processes which have different values for a particular field using the K2 workspace (probably could be automated as well as a deployment step).


 Or just keep processes that don't share environments in separate projects.


 Personally, I just name environment variables that are process specific "ProcessName.FieldName" (you can't do special characters in the Workspace, but you can do it in visual studio)


 Alternately, if you are ambitious, it might be possible to create a new plugin type to handle environment fields per process. That would give you an expandable tree view displaying each process and then environment variables that are associated with that process. I'm just not sure how you'd be able to create new environment variables associated with a particular process given the UI for new field adds, but you could probably work something out.


 

J
Badge +8

Colin,


Correct and I like your approach.  I did not knwo this and it was frustrating to find out after the fact.  So what I am getting at if you want to create an environment specific to a project you will have a to create a unique environment name, regardless of what template the environment resides in.


The problem is plain and simple – when working with the K2 Workspace environments behave different than the string table.  In the K2 Workspace when working with two templates that each have an environment with the same name values in fields are not shared.  However when you deploy the environment values get copied into the same environment string table which are shared because the two environments have the same name (even though they are in different templates). 


There is no usage scenario I am explaining, it is confusing that they behave differently.  The problem would be solved msbuild script generated the environment name as Template.Environment.


I have too much on my plate to be ambitious J


Thanks,
Jason

C
Badge +4

No, I don't believe that is correct.


 When K2 creates the deployment package for your project, it takes whatever environments exist in your active template and creates property groups for them. It doesn't merge all environment names across all templates. 


When you deploy the project, it uses your specified environment to select which string table to create for those processes. The values are whatever existed in the Environment Library for that template and environment name at the time you created the deployment package. 


So separate projects can use separate templates that have the same environment names.


 


 


 


 

J
Badge +8

Colin,


I was not referring to trying to use multiple templates at the same time.  I have some things to do but let me try to write up a little use case and you will see the issue I ran into.


Jason

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings