Not working on WindowsDesktop .Net Core 3.1 project

[Germs2004]

BumpAssemblyVersions 1.6.0 Visual Studio 2019 16.7.6

I have a solution with two .net core 3.1 projects: One is a Windows Forms app (Microsoft.NET.Sdk.WindowsDesktop) and the other is a class library (Microsoft.NET.Sdk). This BumpAssemblyVersions tool works great at modifying the class library's AssemblyVersion, but it doesn't have any effect on the Forms project. I have the same BumpVersionSpec copy/pasted into both of their project files, but the library increments as desired and the forms project file always stays the same.

In the build logs, the section about building the library project has a line saying that the version was bumped, but the section about building the forms project has no such line.

Line from the library project build log (not in the Forms project): 'Core.csproj': Bumped 'AssemblyVersion' from '1.15.20295.1414' to '1.16.20295.1414'

I would be willing to debug this a bit on my side but I have no idea how to attach a debugger and set a breakpoint in the BumpAssemblyVersion code that can watch my actual build happening.

Can you help me either attach a debugger or look into why this problem is happening?

Thank you

[mwpowellhtx]

@Germs2004 Huh, interesting; I would be willing to look into it a bit as far as insights into the Microsoft.NET.Sdk.WindowsDesktop targets are concerned. Prima facie, I cannot fathom any reason why the build targets would be that different, but anything is possible, and obviously per your report, does not seem to work. Much beyond that I do not have the bandwidth, so PRs are welcome. Fair enough?

[mwpowellhtx]

@Germs2004 One thought off the top of my head, if it is following a classical sort of Windows Forms project structure, is there a Properties\AssemblyInfo.cs involved in any way? BAV should support this scenario like any other, as far as I know.

If I can carve out a few minutes to at least introduce a WF project into the solution for test purposes, will do that. But again, PRs welcome.

Cheers :beer:

[Germs2004]

There is no AssemblyInfo.cs file. The closest I see is this: C:\git\MyApp\Module.Host\obj\Debug\netcoreapp3.1\Module.Host.AssemblyInfo.cs

Its contents:

//------------------------------------------------------------------------------
// <auto-generated>
//     This code was generated by a tool.
//     Runtime Version:4.0.30319.42000
//
//     Changes to this file may cause incorrect behavior and will be lost if
//     the code is regenerated.
// </auto-generated>
//------------------------------------------------------------------------------

using System;
using System.Reflection;

[assembly: System.Reflection.AssemblyCompanyAttribute("myname")]
[assembly: System.Reflection.AssemblyConfigurationAttribute("Debug")]
[assembly: System.Reflection.AssemblyFileVersionAttribute("1.0.0.0")]
[assembly: System.Reflection.AssemblyInformationalVersionAttribute("0.1.0.0")]
[assembly: System.Reflection.AssemblyProductAttribute("MyApp")]
[assembly: System.Reflection.AssemblyTitleAttribute("MyAppHost")]
[assembly: System.Reflection.AssemblyVersionAttribute("1.0.0.0")]

// Generated by the MSBuild WriteCodeFragment class.

If I add that file to your "FilesToBump", it will append a AssemblyVersion to the bottom of the file, but then I get an error about duplicate AssemblyVersion because AssemblyVersion is already specified in the csproj file as 1.0.0.0. So I think that isn't the right solution. I'd like the BAV to work on the csproj file just like it does on the class library project.

I am willing to do a PR if I can figure it out, but can you help me get started? I downloaded your code but don't know how to call it or how to attach to the actual build process of my project to walk through your code.

thanks

[Germs2004]

sample project: bavtest.zip

I just created a brand new VS project, added the BAV NuGet package, and added the ItemGroup with a BumpVersionSpec. If you open it and Build multiple times, I expect you'll see that the version is unaffected. Thanks for your time.

[mwpowellhtx]

I can try to offer hints and clues as best I can. The fact that there is apparently an entirely different stack involved, i.e. Microsoft.NET.Sdk.WindowsDesktop versus Microsoft.NET.Sdk may actually mean some of the associated targets are different. It may actually be just that simple, key on those different targets. However, I am not working against WindowsDesktop at the moment, so I have as much interest in making sure it "works" there as well.

At its heart, BumpVersions is literally a Build Task. So this is where I might begin. If things need to be better reported from there, so be it; if bits can be relayed via the targets themselves, that would be better, I think.

I'm open to suggestions, PRs, as I said, nonetheless.

HTH.

[mwpowellhtx]

These are the sorts of issues I loathe...

Strangely I wonder if it could be a dotnet SDK and/or runtime issue. According to this blog, they pin to a prior version and their errors of the same variety go away.

I am checking my installed SDKs, and I have similar symptoms. So I'll try installing a previous stable SDK version and see if that doesn't help resolve the matter as well.

C:\>dotnet --list-sdks
2.1.518 [C:\Program Files\dotnet\sdk]
3.1.402 [C:\Program Files\dotnet\sdk]

And since the WindowsDesktop is in the 3.1 generation, from what I can tell, then that falls squarely in this sort of category.

Similar sorts of reports coming out of a seemingly unrelated entry as well, Strange message....

[mwpowellhtx]

@Germs2004 I see you've been following a couple of the investigatory questions I've been posting. It's all rather muddy territory for me, so any suggestions you may have, I'm open to them.

That said, at the moment it seems the most plausible course of action is to at leat introduce a runtimeconfig.json that helps the environment determine which SDKs and/or runtimes are the most appropriate for this particular tooling, hopefully being that this also yields a productive experience for consumers such as yourself in the WinForms WindowsDesktop space as well.

The question is, "which one" is most appropriate. The tooling itself is targeting netstandard2.0, per se, so at a runtime level, I don't think we care as long as netstandard2.0 is supported. However, as we've seen, it does not seem like we can just allow the VS environment, or other influences, to "just install", prune, whatever, the runtimes willy nilly and expect there be a great outcome, either.

So the choices as far as I am concerned really are, which runtime to use. With the caveats being "it depends", i.e. targeting netcoreapp2.x, netcoreapp3.x, and so on.

[Germs2004]

I've never worked with Build Tasks or runtimeconfig.json before so I don't have much wisdom to offer. I'm actually relieved that my bug report seems to be on target since I was guessing that it was related to 3.1 and Windows Forms.

Since some of the comments on the other threads mentioned that it might be fixed with .NET 5 RC2, I tested it out today, and it did not fix the issue. I tested it with VS 2019 16.8.0 Preview 5 and .NET 5 RC2.20479.15 SDK. BAV continued to work correctly with the class library project, but not on the Windows Forms projects.

[mwpowellhtx]

@Germs2004 Appreciate the feedback. Sounds like it may be worth filing a totally separate issue including repro. Is it possible to target another netcoreapp version? Or is netcoreapp3.1 our only choice?

[mwpowellhtx]

@Germs2004 Also, as a workaround, perhaps establish the WinForms shell as a very thin vernier covering whatever core engine features you are providing, and let that core engine be the thing that informs your versioning. At least for the time being.

[mwpowellhtx]

Alright, it's done. We'll see what we can learn and what our options for workaround, solution, etc, might be.

[mwpowellhtx]

@Germs2004 I have not forgotten, but it is slow receiving feedback. Any additional insights, experimentation you can offer re: this issue or the dotnet/sdk issue would be helpful.

Question helping me better comprehend, I have not worked with the WinForms apart from a cursory keeping informed as to the Microsoft efforts pulling the stacks forward into current dotnet life cycles. Is it fair to say that a default, out of the box WinForms project lands with <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"/>, or is that something else?

At the moment I am thinking this is a gap in the MSBuild targets dealing with ItemGroup variables not being relayed to their respective targets correctly. This after some debug wiring I did in the BAV package and targets to help troubleshoot things a b it more. I may keep that in there for improved diagnostics moving forward, but have not decided yet.

Possibly it is because of the Microsoft.NET.Sdk.WindowsDesktop SDK bits, but I do not know. Pending better mutual comprehension with the Microsoft team via the issue above.

My goal regardless is to at least offer an interim workaround if at all possible. But if it requires deeper introspection, so be it.

[mwpowellhtx]

@Germs2004 Have a look at this line. I would need to blow off the cobwebs as to why I though that condition was necessary. Or perhaps it is something that could better be trained or otherwise reoriented through a set of targets, I don't know. Again, PRs are welcome, since at the moment WinForms is not a priority for me. Appreciate your interest in the project. Cheers. 🍻

[Germs2004]

Fyi, I updated to Visual Studio 16.8.0 and upgraded all my projects to target framework "net5.0-windows", and still have the same problem. Bumping works on the "Class Library" (Sdk="Microsoft.NET.Sdk") project but not the "Windows Application" (Sdk="Microsoft.NET.Sdk.WindowsDesktop") project nor the "Console Application" (Sdk="Microsoft.NET.Sdk.Worker") project.

Since neither the WinForms nor the Console app bump, perhaps it's not a special case with the WinForms app that makes it not work, but maybe a special case with the Class Library that makes it work.

Is it fair to say that a default, out of the box WinForms project lands with <Project Sdk="Microsoft.NET.Sdk.WindowsDesktop"/>, or is that something else?

Correct, I just created a new WinForms project and the project file is this:

<Project Sdk="Microsoft.NET.Sdk.WindowsDesktop">

  <PropertyGroup>
    <OutputType>WinExe</OutputType>
    <TargetFramework>netcoreapp3.1</TargetFramework>
    <UseWindowsForms>true</UseWindowsForms>
  </PropertyGroup>

</Project>

[mwpowellhtx]

@Germs2004 Looks as though we just missed each others' remarks in passing, have a look there 👀 and feel free to submit a PR. I am open to suggestions, maybe the XML screening is over zealous on my part at the time. Or, like I said, maybe there is a way we can better train the screening process via targets, something like that. Thank you.

[Germs2004]

@Germs2004 Have a look at this line.

That's a very interesting line. I removed that line, built a npgk file, installed it, and rebuilt my project.

Microsoft.NET.Sdk = success Microsoft.NET.Sdk.WindowsDesktop = success Microsoft.NET.Sdk.Worker = fail, did not bump

So it fixed the issue with the "WinForms" app, but not the similar issue with the Windows Service "Console" app.

Old code:

if (TryReadingFile(projectFilename, out var given)
                && TryParseDocument(given, out var givenDoc,
                    root => root?.Name.LocalName == "Project"
                            && root.Attribute("Sdk") is XAttribute a
                            && a.Value == "Microsoft.NET.Sdk"))

New code:

if (TryReadingFile(projectFilename, out var given)
                && TryParseDocument(given, out var givenDoc,
                    root => root?.Name.LocalName == "Project"
                            && root.Attribute("Sdk") is XAttribute a))

[Germs2004]

I did some more testing and I think I fixed my issue with the Worker sdk. I had to manually copy all the built files to this location, and then it worked on every project type.

C:\Users\myname\.nuget\packages\bumpassemblyversions\1.5.0

I'll submit a pull request to remove that one line. I hope it doesn't break something else since I'm not sure either why that line was originally added. Thanks for all your help.

[mwpowellhtx]

@Germs2004 I'll take a look at it this weekend, much appreciated.

Just in terms of test environments, I've made an effort there, I believe, to be able to verify engine apart from package deployment environments. But I think I've also made allowances for locally restored package paths, sort of an end to end test if you will. So basically two projects, the unit test projects for engine based testing, and in the usage path for end to end packaging.

[mwpowellhtx]

@Germs2004 Maybe a stupid question, I am trying to add a WinForms project to the usage direct test cases, but I cannot seem to resolve the System.Windows.Form reference correctly. Is it something I need to install? I am running against VS2019 16.7.7, I think, and I added a C# WinForms, but I see no plumbing for anything adding or verifying System.Windows.Forms references to the project. I also verifed that my options include the WinForms feature, which it does. So methinks that something possibly failed to install properly, or I need to update VS2019 itself. I am not running in preview, BTW; I'll let others cut their fingers on cutting edge stuff. I am more interested in stable development path efforts.

[mwpowellhtx]

@Germs2004 Nevermind... I see what I did. I copied and pasted project level version bumping boilerplate, which included a <TargetFramework>netstandard2.0</TargetFramework>... Oof. Removed that line and the <TargetFramework>netcoreapp3.1</TargetFramework> takes effect. All good so far.

[mwpowellhtx]

So far so good in a usage direct scenario:

1>'WindowsFormsApp.csproj': Bumped 'AssemblyVersion' from '1.2.60.0' to '1.2.61.0'
1>'WindowsFormsApp.csproj': Bumped 'FileVersion' from '1.2.60.0' to '1.2.61.0'
1>'WindowsFormsApp.csproj': Bumped 'InformationalVersion' from '1.2.60.0' to '1.2.61.0'

[mwpowellhtx]

Also verified in a variety of project form factors, WinForms, WPF, etc. To the scaffold they are all the same <Project Sdk="..."/> specifically Microsoft.NET.Sdk.WindowsDesktop. But since we now ignore the Sdk XML attribute value itself, it is all the same thing.

[mwpowellhtx]

I'll wrap this one up tomorrow I think. End to end integration testing will not quite be there. Worked out a couple of path issues since I refactored the test solution to $/usage/direct, but now running into what I think is and SDK issue building the test solution projects within the context of a unit test. With a bit of effort, could probably probe the dotnet environment for the path to the installed SDKs and choose the active one and/or appropriate one as the case may be, but will probably leave that as a future exercise.

[mwpowellhtx]

@Germs2004 Okay, verified and closed out. Pushed just now to NuGet feed. There are a handful of unrelated bits that I could follow up on, but as concerns this issue, resolved. Please verify and let me know how it works for you. Thanks again for the interest and the assist!