DesignTime Builds and generated code vs Hot Reload

[andersforsgren]

When using compile-time generation of code such as <GenerateAssemblyInfo> it's difficult to work with differences that may occur in Hot Reload. Example: if using a git-versioning package that checks the commit history (E.g. MinVer https://github.com/adamralph/minver/) it's useful to NOT generate the version information during design time builds, because it slows down the build. The problem then is that Design Time Builds will generate incorrect/modified version info, which can be detected by Hot Reload. If these are edits that cannot be applied, which is the case with versions attributes, then Hot Reload breaks.

I'm having trouble understanding exactly which files are being considered for changes by hot reload, and why it would decide that

ENC0003: Updating 'attribute' requires restarting the application

or

"CS7038: Failed to emit module 'MyModule': Changing the version of an assembly reference is not allowed during debugging: 'MyProject, Version=0.1.0.465, Culture=neutral, PublicKeyToken=null' changed version to '1.0.0.0'.

Is the only way of working around this to generate version info equally even in design time builds? I don't want to update the info (it checks git history), I just want the compilations done both by hot reload and design time builds to use whatever info is already created, if any.

[drewnoakes]

@AArnott do you have any experience with this from https://github.com/dotnet/Nerdbank.GitVersioning?

[andersforsgren]

In my scenario I wouldn’t want to remove the version info out of Debug builds so I can’t just ifdef it out.

If the git ”height” or SHA is part of the version info then obviously adding another commit would change the attributes. But that’s an expected break. Same if * is used for version so build date is part of the version.

Basically what I want to do is generate code in \obj only during “real” (non design time / hot reload) builds. But for design time and hot reload builds I want to include that code, as it looked when it was last generated.

[AArnott]

NB.GV doesn't use *, nor does the attribute arguments change with every build.

[AArnott]

I just created a simple console app with several statements and NB.GV. I stepped through with the debugger and applied a change to one of the statements, and E&C worked without a hitch.

While I've myself seen E&C fail, and seen error list entries that blame changing attributes, I haven't been able to get a reliable repro. Nor do I know which attributes are alleged to have changed, or whether NB.GV owns them.

[andersforsgren]

Is NB.GV actively avoiding the generation of version information during design time builds?

I'm struggling to find any info on the relationship between "hot reload" (Edit-and-continue - which I assume is a different name for the same thing) and DesignTimeBuilds. Specifically: what msbuild targets are executed in what circumstances.

E.g do hot reload compilations invoke msbuild at all? If so, which targets are executed and with what properties? If a target exeutes e.g. BeforeTargets="CoreCompile" and creates and adds (Compile Include) a file under /obj , then that target must be executed also during hot reload, or code will break. There seems to be precious little documentation about exactly what goes on during these compilations.

I have worked around it in one case by generating files not under the intermediate dir, but instead directly under the source dir, where it will always be compiled due to the **/*.cs default compilation items. That way during hot reload, the generated file from the last compilation is picked up, and the version attributes don't change.

[AArnott]

Is NB.GV actively avoiding the generation of version information during design time builds?

No. In fact the generated code file includes internal APIs that user code in the assembly may reference, so generating the file during design-time builds is a requirement for a good user experience. But when the generated code is the same as the code generated from a prior build (design-time or otherwise) then the pre-existing file is not overwritten.

Whether the generated code has compiled or not, and whether it's a full build or a design-time build, the Compile item is emitted.

[joriverm]

Hi,

we just stumbled to this discussion/issue and are using minver for our product versioning.
is there an update to this issue? will minver need an update to not apply versioning in debug builds?