4

tl;dr: How to modify the .csproj file during publishing with ClickOnce while executing pre-build events?

Long: I'm using TFS hosted by Microsoft for version control of my solution.

When publishing with ClickOnce, I get the latest revision number + 1 without problems. I also can successfully write the new version number into the .csproj file outside my build-process.

The problem is, that the .csproj file doesn't get updated during the build process - it might be in a write-lock. I get a notification inside Notepad++ about the modification of the file, but the file still contains the old version and VS didn't notice any changes.

The only solution by now I found to resolve this issue: Move the revision update into the post-build events and add 2 instead of one to the actual revision number. Unfortunately this would cause that revision number would be out of date whenever other developers check-in code.

Stefan Over
  • 5,851
  • 2
  • 35
  • 61
  • 1
    Updating the project file on the fly is a bad idea, you're probably better off creating a target file that updates the value of the variable at the right stage. Should you want to try what you're doing right now, turn off hosting for msbuild. http://blog.jessehouwing.nl/2012/06/just-in-time-updating-of-source-files.html – jessehouwing Jul 18 '13 at 18:12
  • @jessehouwing I agree with your idea. But wouldn't be any stage - no matter where I place it - cause changes on the .csproj file anyway? MsBuild reads the version number of the csproj file and not from e.g. the AssemblyInfo.cs when publishing with ClickOnce. – Stefan Over Jul 18 '13 at 20:55

1 Answers1

1

Ok, strike that... :(.

After some more diffing, you'll need to override the GenerateApplicationManifest target to get this to work. That target doesn't use a *DependsUpon propertygroup, so it's harder to overwrite. The whole flow is defined in the Microsoft.Common.Targets file which you can find in the %windir%\Microsoft.NET\Framework{cpu}\{version} folder.

See also:

jessehouwing
  • 106,458
  • 22
  • 256
  • 341
  • Using the last part: `1.1.0.$(ApplicationRevision)` into your setup leads into a false output. Output is 0.0.2.246 instead of 1.1.0.254 – Stefan Over Jul 19 '13 at 11:18
  • After some more diffing, you'll need to override the `GenerateApplicationManifest` target to get this to work. That target doesn't use a "*DependsUpon" propertygroup, so it's harder to overwrite. The whole flow is defined in the Microsoft.Common.Targets file which you can find in the `%windir%\Microsoft.NET\Framework{cpu}\{version}` folder. – jessehouwing Jul 19 '13 at 14:30
  • Wow...i quickly scanned the `Microsoft.Common.Targets` file. This seems to be a huge task to modify it. And I won't be able to publish applications that don't run on a TFS, due to the broken behavior. I think modifying the build process to grab the TFS revision during the build process via a task is a bad idea. What about letting the publish process "fail", if it's published with an outdated revision and force the developer to publish it again? – Stefan Over Jul 19 '13 at 15:26
  • You don't have to modify the file, just re-declare the target in a file which is imported later (or at the bottom of your .csproj). The latest one wins. – jessehouwing Jul 19 '13 at 18:58