Skip to content
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

Fixes Issue #4705 - Wrong version numbers in dlls #4706

Merged
merged 27 commits into from
May 26, 2024
Merged

Conversation

OsirisTerje
Copy link
Member

Fixes #4705

src/AssemblyInfo.g.cs Outdated Show resolved Hide resolved
Copy link
Member

@manfred-brands manfred-brands left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@OsirisTerje Sorry for the delay, I was off sick and couldn't concentrate enough to do reviews.
I also like code generation, but I do think your second option is nicer.
I think we can remove a lot of conditionals in the other projects by utilizing the AssemblyConfiguration set in the Directroy.Build.props

build.cake Outdated Show resolved Hide resolved
src/NUnitFramework/Directory.Build.props Outdated Show resolved Hide resolved
src/NUnitFramework/Directory.Build.props Outdated Show resolved Hide resolved
src/NUnitFramework/Directory.Build.props Outdated Show resolved Hide resolved
src/NUnitFramework/framework/nunit.framework.csproj Outdated Show resolved Hide resolved
src/NUnitFramework/nunitlite/nunitlite.csproj Outdated Show resolved Hide resolved
@OsirisTerje OsirisTerje changed the title Fixes Issue #4705 Fixes Issue #4705 - Wrong version numbers in dlls May 13, 2024
Copy link
Member

@manfred-brands manfred-brands left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

You added various unnecessary null suppression operators (!).
All of them are unnecessary as NUnit.Analyzer does the suppressing for us as it knows those cannot be null.

Copy link
Member

@manfred-brands manfred-brands left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Still some issues.

CakeScripts.Tests/Usings.cs Show resolved Hide resolved
src/NUnitFramework/tests/CakeTests.cs Outdated Show resolved Hide resolved
src/NUnitFramework/tests/WorkItemTests.cs Outdated Show resolved Hide resolved
src/NUnitFramework/TestBuilder.cs Outdated Show resolved Hide resolved
CakeScripts.Tests/VersionParsersTests.cs Outdated Show resolved Hide resolved
Copy link
Member

@manfred-brands manfred-brands left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I raised one issue in the build.cake script.
It was mentioned originally in my first review but got lost in the further discussions.
I pushed up a commit for that.

One thing though is that if I build this locally it build version: 4.0.0-alpha.88
So maybe the code relies on annotated tags instead of normal ones.
git describe returns 4.0.0-alpha-244-ga604a39ca

I do see confusing tags in the repository some have a v prefix others don't

4.0.0-alpha
4.1.0
4.1.0-alpha.0
v4.0.0
v4.0.0-beta.1
v4.0.1

Note that the CI build doesn't fetch any tags and creates version 0.0.0.0:

image

I added a commit to fetch the tags to see what it does. You can revert this as it isn't needed for CI builds only for publications.
It seems to create 4.2.0 versions:

image

MinVer must pick up the 4.1.0 tag and create the next release.
There are various properties for MinVer we can use to tailor this.

CakeScripts.Tests/CakeScripts.Tests.csproj Show resolved Hide resolved
CakeScripts/VersionParsers.cs Outdated Show resolved Hide resolved
build.cake Outdated Show resolved Hide resolved
build.cake Outdated Show resolved Hide resolved
OsirisTerje and others added 2 commits May 25, 2024 11:22
@OsirisTerje OsirisTerje merged commit 2d20f5d into master May 26, 2024
5 checks passed
@OsirisTerje OsirisTerje deleted the fileversionissue branch May 26, 2024 19:47
@manfred-brands
Copy link
Member

@OsirisTerje for some reason dotnet test no longer finds any tests in master after this commit got merged.

If I go a commit before this dotnet test finds test, afterwards not anymore.
I looked at the changes and this doesn't change anything except versions.
Not sure how the adapter finds tests, but the adapter is the same in all cases, so it must be something in NUnit itself.
I tried dotnet test -- NUnit.DebugExecution=true but your blog seems to indicate it only works with a debug version of the adapter and my PC refused to execute any non-signed PS1 scripts.

@stevenaw Can you confirm this behaviour?

@stevenaw
Copy link
Member

stevenaw commented Jun 2, 2024

I think I can confirm. Based on the following to test:

dotnet clean
dotnet build
dotnet test

I tried checking out the previous merge commit (376b434) and could run all the tests that way. Presently, it seems like only the cake tests are running. This is a subset of the output I see presently:

Starting test execution, please wait...
A total of 1 test files matched the specified pattern.
No test is available in .\nunit\src\NUnitFramework\tests\bin\Debug\net8.0\nunit.framework.tests.dll. Make sure that test discoverer & executors are registered and platform & framework version settings are appropriate and try again.

Additionally, path to test adapters can be specified using /TestAdapterPath command. Example /TestAdapterPath:.

I converted the absolute path in the the message to relative for brevity

@OsirisTerje
Copy link
Member Author

OsirisTerje commented Jun 2, 2024

I do see the same using dotnet test, and build --target=test (cake tests) still works.

How can version number changes do this ???

In VS I only see the single test in CakeScripts.Tests
image

That project only has net 6.0

@mikkelbu
Copy link
Member

mikkelbu commented Jun 5, 2024

How can version number changes do this ???

The only thing I can thing of - without debugging into the code and I don't know much about versioning in .NET - is that the IsSupportedTestFramework - https://github.com/nunit/nunit-console/blob/6ab7411d454ab2563426fdb60a9cdff7be655bb4/src/NUnitEngine/nunit.engine.core/Drivers/NUnit3DriverFactory.cs#L21-L24 - cannot determine that the major version is above or equal to 3.

Looking at the product versions it seems that we now add a lot of "prerelease" information that might confuse the validation (comparing NUnit.4.2.0-alpha.0.17.nupkg and NUnit.4.2.0-alpha.0.21.nupkg from myget)
image
image

@OsirisTerje
Copy link
Member Author

Just checking: Product Version == Informational Version, and should into be used in the comparison.
FileVersion is the one being returned in the check in the engine, so it should work (I know, famous last words.....)

Am I right or wrong here?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

The dll's in the release 4.1 has version 4.0.1
5 participants