Mar 1, 2010 at 4:24 PM
Edited Mar 4, 2010 at 3:12 PM
The Deployment Framework has always enforced a project folder and file naming structure, with the "custom paths" option allowing a way to work around the restrictions. The "custom paths" option has never been well tested,
nor has it fully supported all of the Deployment Framework's functionality. The required naming structure has always been a significant barrier to developers wanting to utilize the Framework with existing BizTalk projects, and it forced sometimes-frustrating
The current structure is fairly straightforward: the name of your output files (Project.Schemas.dll), minus extension (Project.Schemas) must be the same as the project folder name. By default the names are based on the ProjectName property defined
in the .btdfproj file. For example, the default value of the <Schemas> property is $(ProjectName).Schemas. That means that under your solution folder you would have a BizTalk project in a subfolder named (assuming $(ProjectName) = 'Test')
Test.Schemas, and the output file would be Test.Schemas\bin\debug\Test.Schemas.dll (or \release\). The key restriction is that the project folder name must equal the output file name. If you wanted to call your project folder "Schemas",
then your output would have to be Schemas.dll. Not ideal by any means.
For these reasons, I am introducing a possibly breaking change in the next beta release which will lift the naming restrictions.
You may or may not be affected by this change depending on your specific configuration. Let's identify two scenarios:
- You are currently using today's folder and DLL naming structure. In your .btdfproj file, you do
not define the <Schemas>, <Orchestrations> or any of the other elements listed at the bottom of this post. You are
not setting the UseCustomDirs property to true. In this scenario, you WILL NOT be affected by this change.
Today's project and DLL naming structure will remain in effect.
- You are setting the UseCustomDirs property to true or you are overriding the default settings for <Schemas>, <Orchestrations> and the other elements listed at the bottom of this post.
In this scenario, you WILL be affected by this change.
If you are affected, here's an example of the change in your .btdfproj file using the <Schemas> element. The same generally applies to the other elements listed at the bottom of this post.
Other than some restructured XML (which is actually standard MSBuild syntax), the most significant change that you'll notice is the inclusion of the file path. The former "magic" of the Deployment Framework is gone, and it will no longer
automatically create the path. You'll now be required to specify it yourself, which gives you unlimited flexibility. If you need to reference a common assembly that is out of your control, you can easily do that (the Common.Schemas.dll example).
If you want to build to a common bin directory instead of bin\debug and bin\release, you can do that.
This change will affect <Orchestrations>, <Schemas>, <Transforms>, <Components>, <Pipelines>, <PipelineComponents>, <CustomFunctoids>, <BamDefinitions> and <AppsToReference>, <AdditionalAssemblies>,
<ExternalAssemblies> and <FilesToXmlPreprocess>. The <UseCustomDirs> property will be deprecated, as it should no longer be necessary.
You can expect to see this change in the next beta release. In the meantime, please reply here with any feedback, positive or negative, and let me know what you think about this change.
Sounds reasonable. My current client was in the habit of putting everything in one project, with folders for schemas, maps, orchs, etc...
Mar 5, 2010 at 4:43 PM
This discussion has been copied to a work item. Click
here to go to the work item and continue the discussion.