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
{{ message }}
This repository has been archived by the owner on May 17, 2024. It is now read-only.
I just upgraded a few of my old .NET Framework projects (old style csproj) to SDK-style in preparation of getting more things done moving towards .NET 6, and one thing that happened for all projects was how my custom imports were removed.
My project files usually looked like this, to generalize/centralize a few things (where I want consistency across muany projects of a solution):
AssemblyInfo.targets has a few custom targets that fill in AssemblyInfo values; and in turn includes a common AssemblyInfo.props that defines things like base version numbers, the company name to use (which affects how settings are stored in %APPDATA%), copyright info etc. Common.props defines things like the C# language version, Deterministic build rules, etc.
(Note: I know that both could just as well be achieved by using Directory.Build.targets and Directory.Build.props, but this kinda happened before I knew about those; and sometimes I had one-offs where I couldn't just apply things to all projects)
After running the conversion step with upgrade-assistant version v0.3.330701+fa00bab2d06aab9c710c344c0f32440ad4eb8410 (which I mainly used because I had it; I don't have try-convert installed manually) they were silently removed along with other .targets that were expected to go away.
According to the console output, it used the embedded/bundled try-convert with version 0.3.330701+3799b6849a9457619660a355ca9111c050b0ef79 (and thats pretty much the most recent commit to this date).
The obvious result of this was that any AssemblyInfo was missing from the build output, as if never set anywhere.
It's not unfixable on my end or anything (and pretty straight-forward as well, since all my projects are under version control); but it is somewhat annoying. Plus the fact that it is supposedly supported but I didn't see any indication of it makes me wonder if theres a different bug sleeping somewhere.
The text was updated successfully, but these errors were encountered:
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
I just upgraded a few of my old .NET Framework projects (old style csproj) to SDK-style in preparation of getting more things done moving towards .NET 6, and one thing that happened for all projects was how my custom imports were removed.
My project files usually looked like this, to generalize/centralize a few things (where I want consistency across muany projects of a solution):
AssemblyInfo.targets
has a few custom targets that fill in AssemblyInfo values; and in turn includes a commonAssemblyInfo.props
that defines things like base version numbers, the company name to use (which affects how settings are stored in%APPDATA%
), copyright info etc.Common.props
defines things like the C# language version, Deterministic build rules, etc.(Note: I know that both could just as well be achieved by using
Directory.Build.targets
andDirectory.Build.props
, but this kinda happened before I knew about those; and sometimes I had one-offs where I couldn't just apply things to all projects)After running the conversion step with
upgrade-assistant
versionv0.3.330701+fa00bab2d06aab9c710c344c0f32440ad4eb8410
(which I mainly used because I had it; I don't havetry-convert
installed manually) they were silently removed along with other.targets
that were expected to go away.According to the console output, it used the embedded/bundled
try-convert
with version0.3.330701+3799b6849a9457619660a355ca9111c050b0ef79
(and thats pretty much the most recent commit to this date).The obvious result of this was that any AssemblyInfo was missing from the build output, as if never set anywhere.
I found #370 (and the PR #378), which was supposedly fixed; but I never saw this
Console.WriteLine
happen:https://github.com/mjrousos/try-convert/blob/ee032544590c99d818aacb66130048d20413780f/src/MSBuild.Conversion.Project/ProjectRootElementExtensionsForConversion.cs#L25-L28
It's not unfixable on my end or anything (and pretty straight-forward as well, since all my projects are under version control); but it is somewhat annoying. Plus the fact that it is supposedly supported but I didn't see any indication of it makes me wonder if theres a different bug sleeping somewhere.
The text was updated successfully, but these errors were encountered: