-
Notifications
You must be signed in to change notification settings - Fork 0
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Not working on WindowsDesktop .Net Core 3.1 project #6
Comments
@Germs2004 Huh, interesting; I would be willing to look into it a bit as far as insights into the |
@Germs2004 One thought off the top of my head, if it is following a classical sort of Windows Forms project structure, is there a 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 🍺 |
There is no AssemblyInfo.cs file. The closest I see is this: Its contents:
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 |
sample project: 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. |
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. At its heart, I'm open to suggestions, PRs, as I said, nonetheless. HTH. |
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.
And since the WindowsDesktop is in the Similar sorts of reports coming out of a seemingly unrelated entry as well, Strange message.... |
@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 The question is, "which one" is most appropriate. The tooling itself is targeting So the choices as far as I am concerned really are, which runtime to use. With the caveats being "it depends", i.e. targeting |
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. |
@Germs2004 Appreciate the feedback. Sounds like it may be worth filing a totally separate issue including repro. Is it possible to target another |
@Germs2004 Also, as a workaround, perhaps establish the |
Alright, it's done. We'll see what we can learn and what our options for workaround, solution, etc, might be. |
@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 At the moment I am thinking this is a gap in the MSBuild targets dealing with Possibly it is because of the My goal regardless is to at least offer an interim workaround if at all possible. But if it requires deeper introspection, so be it. |
@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. 🍻 |
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.
Correct, I just created a new WinForms project and the project file is this:
|
@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. |
That's a very interesting line. I removed that line, built a npgk file, installed it, and rebuilt my project. Microsoft.NET.Sdk = success So it fixed the issue with the "WinForms" app, but not the similar issue with the Windows Service "Console" app. Old code:
New code:
|
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.
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. |
@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 |
@Germs2004 Maybe a stupid question, I am trying to add a |
@Germs2004 Nevermind... I see what I did. I copied and pasted project level version bumping boilerplate, which included a |
So far so good in a
|
Also verified in a variety of project form factors, WinForms, WPF, etc. To the scaffold they are all the same |
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 |
@Germs2004 Okay, verified and closed out. Pushed just now to |
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
The text was updated successfully, but these errors were encountered: