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
If multiple solutions are in a single repository, then there will be a race condition of sorts that happens, since the SharedAssemblyInfo.cs is shared amongst all solutions / projects sharing the given package.
So if solution A is using version 1.0.0.0 and solution B is using version 2.0.0.0... and they each have multiple projects, but live in the same solution, there may be issues where A projects end up with 2.0.0.0 and B projects end up with 1.0.0.0.
Each project in each solution recreates the SharedAssemblyInfo.cs file before building / incorporating it.... but there's a window of time between when the file is written and it's used in the build -- so there is an opportunity for another csproj file to blow away the file before it's compiled with version information that may not be correct for that project. Perhaps this generated file can be placed moved to the build configuration obj directory instead of using something underneath of the nuget packages folder?
Chew on this for a bit... still need to be able to reference the file from inside the csproj, and need to output the file to a place that is not excluded from DVCS.
Admittedly this is an edge case, and perhaps should be punted on... but documented anyhow. No real world issues with this at the moment.
The text was updated successfully, but these errors were encountered:
If multiple solutions are in a single repository, then there will be a race condition of sorts that happens, since the SharedAssemblyInfo.cs is shared amongst all solutions / projects sharing the given package.
So if solution A is using version 1.0.0.0 and solution B is using version 2.0.0.0... and they each have multiple projects, but live in the same solution, there may be issues where A projects end up with 2.0.0.0 and B projects end up with 1.0.0.0.
Each project in each solution recreates the SharedAssemblyInfo.cs file before building / incorporating it.... but there's a window of time between when the file is written and it's used in the build -- so there is an opportunity for another csproj file to blow away the file before it's compiled with version information that may not be correct for that project. Perhaps this generated file can be placed moved to the build configuration obj directory instead of using something underneath of the nuget packages folder?
Chew on this for a bit... still need to be able to reference the file from inside the csproj, and need to output the file to a place that is not excluded from DVCS.
Admittedly this is an edge case, and perhaps should be punted on... but documented anyhow. No real world issues with this at the moment.
The text was updated successfully, but these errors were encountered: