Is Hot Reload a supported Scenario for MinVer?

[andersforsgren]

I notice that it can be tricky to get Hot Reload working with MinVer. Intermittently VS Hot Reload will refuse to emit the updated assembly because e.g.

error CS7038: Failed to emit module 'OneAssembly': Changing the version of an assembly reference is not allowed during debugging: 'AnotherAssembly, Version=1.2.3.4 changed version to '0.0.0.0'.

If I understand correctly, the Hot Reload compilation is run as a "Design Time Build"? (p:DesignTimeBuild=true) which effectively disables MinVer. Alternatively, what I'm seeing is a Design Time Build run by the IDE while debugging (since source is edited in the IDE). Regardless: this design time build is started and runs the GenerateAssemblyInfo steps. If the configuration is to always generate assembly info, i.e.

<GenerateAssemblyInfo>true</GenerateAssemblyInfo>`

Then during design time builds, the assembly will get version 1.0.0.0. This will be different from the desired MinVer version 1.2.3.4 so Hot reload will fail. If the configuration is instead

<GenerateAssemblyInfo Condition="$(DesignTimeBuild) == false">true</GenerateAssemblyInfo>`

Then both MinVer and GenerateAssemblyInfo are run only in real builds and not design time builds. But now no AssemblyInfo.cs file is included in the compilation, so while debugging, you can still fail as assemblies will get version = '0.0.0.0' instead.

I understand it's not a good idea to run expensive tasks in Design Time Builds, but is there any way to prevent either the version flip/flopping in obj\Debug\SomeAssembly.AssemblyInfo.cs between 1.0.0.0 and the MinVer data? What one would really want here is for design time builds to use the previously generated assembly info from the last real builld, and not generate any new info but also not compile without assembly info.

[adamralph]

I'm not sure I can help a great deal, since I'm not familiar with Hot Reload, but if you can figure out which target(s) are invoked in that scenario which require MinVer to have run beforehand, you could add a custom target to your csproj file to ensure it does. E.g.:

<Target Name="MinVerHotReload" BeforeTargets="HotReloadTarget1;HotReloadTarget2" DependsOnTargets="MinVer"/ >

If you can figure out those targets, then I wouldn't mind adding support for this in MinVer itself.