File lists becoming ItemGroups

[tfabraham]

REVISED 3/3/2010   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 naming compromises.   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 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 , 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 , 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 element. The same generally applies to the other elements listed at the bottom of this post.   OLD:    

... $(ProjectName).Schemas,Common.Schemas ...

  NEW:    

..\$(ProjectName).Schemas\bin\$(Configuration) ..\ReferenceAssemblies

  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 , , , , , , , , , , and . The 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.   Thanks,Tom

This work item was migrated from CodePlex

CodePlex work item ID: '6134' Assigned to: 'tfabraham' Vote count: '1'

[tfabraham]

[UnknownUser@3/5/2010] Resolved with changeset 37757.

[tfabraham]

[giuliov@3/9/2010] You may have a compatibility mode based on the existence of the properties (infact Item and Property namespaces are distinct); something like:

Item merge all declarations.

[tfabraham]

[tfabraham@3/9/2010] True, although it would take more than just that fragment. The new script assumes that the Include is a bare filename with no path, which is not guaranteed by merging in existing values. I'd have to account for that and probably some other situations. Although it may cause some (very) short term pain, many users will not be affected at all, and those with custom paths will be able to convert an average solution in maybe 10 minutes. Thanks for the feedback!

[tfabraham]

[UnknownUser@3/15/2010]

[tfabraham]

[UnknownUser@3/15/2010] Resolved with changeset 38298.

[tfabraham]

[UnknownUser@3/15/2010]

[tfabraham]

[UnknownUser@3/15/2010] Resolved with changeset 38302.

[tfabraham]

[UnknownUser@2/21/2013]

[tfabraham]

[UnknownUser@5/16/2013]