If you have the following setup:
The transformed foo.xml does not make it to the output folder for ClassLibraryA, it should.
Last sentence: "The transformed foo.xml does not make it to the output folder for ClassLibraryA, it should." It should be ClassLibraryB, not A.
Sayed, Is this the issue where we are not using the item right to pass the location of the transformed item, or is the item missing altogether? Is the item set as type "Content" in the project, or is the item check to send to the build output "If Newer" or "Always"? These two items are supposed to control XML and other "content" types files. And, I am not sure, but I seem to recall that while we might be able to fix the "content" issue, the copy to build output may be something hard coded that looks at the project file, not the build outputs. (I may have that backwards.) ChuckEng@Microsoft.com Date: Mon, 24 Sep 2012 12:36:37 -0700
Subject: Re: [slow-cheetah] Transforms are not going into output dir for referenced projects (#34)
Reply to this email directly or view it on GitHub.
No I think you are thinking of an issue relating to app.config where some tooling continues to pick the source app.config rather than using the TargetPath as they should.
In this case the user right-clicks and selects transform on a file other than app.config. After that the expectation is that the transformed file will make it to the output folder of the secondary output. This is the behavior that Copy to Output has today. I think I need to ensure that transformed files will be in that same set of files. I'll have to investigate it to find the correct fix.
This guy has an approach that may work better: http://blogs.clariusconsulting.net/kzu/how-to-apply-build-configuration-transformations-on-non-web-projects/
updates to copy referenced .dll.config to output path. Resolved #34. …
…Changes for 2.5 release
Thanks for the link. I have implemented this feature and it is now been released in 2.5 of SlowCheetah at http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5.
If you have two projects
Both the ClassLibraryA and WindowsFormsB have app.config files, and they both use SlowCheetah. When you build WindowsFormsB the transformed app.config for WindowsFormsB is WindowsFormsB.dll.config and the transformed file ClassLibraryA.dll.config are both in the output directory of WindowsFormsB.
You can turn this behavior off by creating an MSBuild property (or env variable) ScAllowCopyReferencedConfig to false.
If you try it and have issues please re-open this and I'll take a look at it.
I'm not sure if this feature works exactly as you describe it.
Considering your scenario, where WindowsFormsB does have SlowCheetah installed, but ClassLibraryA DOES NOT have it.
According to my observations any .config in ClassLibraryA is stilled copied over to the output directory of WindowsFormsB. That result is unexpected since ClassLibraryA does not have SlowCheetah installed.
Thanks to you for including that flag to turn this behavior off! That's the workaround I'm using.
I have other .config files beside the app.config in my projectA that I would like included in the output folder of projectB where projectB is the one that I'm building and projectB references projectA.
This method includes the app.config files as projectA.dll.config, but I would like for a larger set of transormed files from one specific project to be included in the final output.
Is there any support for this at all currently?