This project is read-only.

Task fails when target missing


Because the target file is set not to be checked in, it does not exist in source control. This is only an issue when you checkout the repo to a new computer or location on the existing computer. The process then cannot build correctly because this file is missing.

Any chance you can add a check, and to create a new (empty) target file? I was able to do it by updating the VersionFile Execute method:
    public override bool Execute()
            // Read content of the template file
            string content = File.ReadAllText(TemplateFile);

            // Replace tokens in the template file content with version info
            content = tokenReplacer.Replace(content);

            if (!File.Exists(DestinationFile))

            // Write the destination file, only if it needs to be updated
            if (!File.Exists(DestinationFile) || File.ReadAllText(DestinationFile) != content)
                File.WriteAllText(DestinationFile, content);

            return true;
        catch (BuildErrorException e)
            return false;
But it's keeping to file locked so it's not able to update it correctly in the build process.

Maybe I'm missing something and the application already does this, but as far as I can tell this function is missing. Or perhaps this is by design.


AlanBarber wrote Apr 17, 2012 at 8:16 PM

Looks like the file lock might be an issue with how msbuild and VS work... i found a stack overflow question related to custom build tasks and file locks that might be realevent.

jdaley wrote Apr 29, 2012 at 6:16 AM

Can anyone give steps to reproduce this problem?

I tried this with a project that uses MSBuildVersioning.dll:
  1. Clone the repo (or delete VersionInfo.cs from an existing repo)
  2. Open the solution
  3. Build
When the solution opens, VersionInfo.cs appears in the Solution Explorer with an exclamation icon to indicate the file is missing, as expected, but building it works fine. VersionInfo.cs is created during the first build.

RichardJFoster wrote Sep 11, 2014 at 3:34 PM

This issue appears to go away with the NuGet packaged version of MsBuild, presumably because that sets the template file to VersionInfo.cs (with a build property of "None"), and flags VersionInfo.designer.cs (the generated file, and the one that is compiled) as being dependent on VersionInfo.cs. At least in VS 2013 this seems to keep Visual Studio quite happy. :-)