You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When looking for _FilesToTransform, you correctly look only in the project file, but when you look for the transform file (e.g. App.Debug.Config), you're looking in the file system instead, which means you may pick up files which have been removed from the project (but left on disk), or which belong to another project file which shares the source directory (e.g. if someone has a pair of project files which compile the same code against CLR2 and CLR4)
It seems to me that you should be looking for items within the project that are DependentUpon the App.config file you already found.
The text was updated successfully, but these errors were encountered:
I think this is more feature than bag. We use this approach to handle "release" transforms, that contains security sensitive data (passwords, keys etc.). So we not commit this transforms in the repository but put it on the build server manualy. And this works perfect.
Having a different file on your build server than what you have checked into source code would still be possible -- put a blank one in source control and replace it on your build server (or just add it to the .proj but leave it out of source control entirely -- visual studio will warn about the file, but it should still build, and the warning icon will serve as a reminder that you actually have an unlisted file on your build server).
The point is that .*proj file should be the authority on what files are part of the project, just based on the principle of least surprise: when I "remove" a file from the project, the build shouldn't use it.
You can imagine that I was surprised, then confused, and eventually frustrated and annoyed when I "removed" the transform files from my project and rebuilt and found that my App.config was still being transformed. I had to dig into the source for my project file, then the slow-cheetah targets file before I discovered why -- and although I found a temporary workaround (manually set false on the app.config file in my .csproj) most users won't have the know-how to go through the targets files to figure that out, and will have to guess that the problem is that the files are still on disk.
Visual Studio warning is not an option for us. If I put blank file to source control, on build server this file override my release settings after new version is pulled from the VCS.
I think the better solution is to have a property that can disable this behaviour. And add description of this issue to documentation.
When looking for _FilesToTransform, you correctly look only in the project file, but when you look for the transform file (e.g. App.Debug.Config), you're looking in the file system instead, which means you may pick up files which have been removed from the project (but left on disk), or which belong to another project file which shares the source directory (e.g. if someone has a pair of project files which compile the same code against CLR2 and CLR4)
It seems to me that you should be looking for items within the project that are DependentUpon the App.config file you already found.
The text was updated successfully, but these errors were encountered: