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

dotnet does not generate fsproj.metaproj file, but build process seems to require it #2275

Closed
rainersigwald opened this issue Jul 10, 2017 · 22 comments

Comments

@rainersigwald
Copy link
Member

From @colinbowern on June 25, 2017 20:45

Steps to reproduce

  1. Install .NET Core on WSL Bash per the .NET Core Step-by-Step instructions
  2. Run through steps to get started with F# on the CLI through to completing "Writing a Class Library" on the Get started with F# with the .NET CLI documentation
  3. Run "dotnet build"

Expected behavior

Class library compiles

Actual behavior

Failed with error MSB4025: The project file could not be loaded. Could not find file '/mnt/c/Users/colinb/Projects/TestProject/src/Library/Library.fsproj.metaproj

No tooling along the way creates a metaproj file. This file does not exist.

Environment data

dotnet --info output:

.NET Command Line Tools (1.0.4)

Product Information:
Version: 1.0.4
Commit SHA-1 hash: af1e668

Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/1.0.4

Copied from original issue: dotnet/cli#7000

@rainersigwald
Copy link
Member Author

From @dmbarbour on June 29, 2017 16:16

I'm seeing the same problem with any attempt to create a solution. Steps to reproduce:

mkdir tmp; cd tmp
mkdir A; cd A; dotnet new classlib -lang f#; cd ..
dotnet new sln
dotnet sln add A/A.fsproj
dotnet build

Error at this point is: /tmp/A/A.fsproj.metaproj : error MSB4025: The project file could not be loaded. Could not find file '/tmp/A/A.fsproj.metaproj'. Same dotnet version as @colinbowern, above.

Note: this issue does not appear with C# projects, only for the F# projects. Further, the dotnet restore from the toplevel solution seems to ignore all the F# projects and only restores C# projects.

@rainersigwald
Copy link
Member Author

From @dmbarbour on June 29, 2017 23:29

I have a workaround: I'm just using a toplevel project instead of a toplevel solution.

@rainersigwald
Copy link
Member Author

From @livarcocc on July 10, 2017 21:23

@rainersigwald Is this something else that msbuild needs to address? Why would it fail to generate the metaproj for a solution with fsprojs? Are we setting the wrong project type, maybe?

@rainersigwald
Copy link
Member Author

rainersigwald commented Jul 12, 2017

EDIT: Ignore this! Info is superseded.

@colinbowern I can't reproduce this with your instructions. I ran into #2022, but after applying the workaround for that I can successfully build the solution.

@dmbarbour's repro does error for me though.

Workarounds

  1. Don't use the .sln to build; instead build at your "overall" project or use a top-level "traversal" project that points to your projects (as mentioned dotnet does not generate fsproj.metaproj file, but build process seems to require it #2275 (comment)).

  2. Set the environment variable MSBuildEmitSolution=1. This causes MSBuild to emit the files to disk (for debugging), but then they exist and can be found. I don't recommend checking them in.

Example, after applying the workaround for #2022.

$ MSBuildEmitSolution=1 dotnet build tmp.sln
Microsoft (R) Build Engine version 15.1.1012.6693
Copyright (C) Microsoft Corporation. All rights reserved.

  A -> /mnt/s/work/fs/tmp/A/bin/Debug/netstandard1.6/A.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:10.29

@rainersigwald
Copy link
Member Author

Sorry, that was bad analysis!

I'm not sure I can reproduce this issue. I see a different error (warning MSB4046) when following @dmbarbour's repro steps.

My issue is a (bizarre!) manifestation of #2022. After changing relative-path slash directions in the .sln file, I can build successfully.

The problem isn't that the .metaproj doesn't exist (it does, in memory); it's that its contents only emit the error:

  <Target Name="Build" Condition="'$(CurrentSolutionConfigurationContents)' != ''">
    <Warning Text="Error reading project file &quot;A\A.fsproj&quot;: Could not find file %27/mnt/s/work/fs/temp/A\A.fsproj%27." Code="MSB4046" HelpKeyword="MSBuild.SolutionParseErrorReadingProject" />
  </Target>
  <Target Name="Clean" Condition="'$(CurrentSolutionConfigurationContents)' != ''">
    <Warning Text="Error reading project file &quot;A\A.fsproj&quot;: Could not find file %27/mnt/s/work/fs/temp/A\A.fsproj%27." Code="MSB4046" HelpKeyword="MSBuild.SolutionParseErrorReadingProject" />
  </Target>
  <Target Name="Rebuild" Condition="'$(CurrentSolutionConfigurationContents)' != ''">
    <Warning Text="Error reading project file &quot;A\A.fsproj&quot;: Could not find file %27/mnt/s/work/fs/temp/A\A.fsproj%27." Code="MSB4046" HelpKeyword="MSBuild.SolutionParseErrorReadingProject" />
  </Target>
  <Target Name="Publish" Condition="'$(CurrentSolutionConfigurationContents)' != ''">
    <Warning Text="Error reading project file &quot;A\A.fsproj&quot;: Could not find file %27/mnt/s/work/fs/temp/A\A.fsproj%27." Code="MSB4046" HelpKeyword="MSBuild.SolutionParseErrorReadingProject" />
  </Target>

That's what the solution-parser does when it can't open the project.

I also don't seem to be able to reproduce the MSB4025 using a .NET Core SDK 2.0.0-preview build on macOS.

If you see this (@colinbowern especially), I'd like to know more about how your project is set up. A zip file might also be useful.

@rainersigwald
Copy link
Member Author

Closing due to lack of response. If you see this and can give more details about your code, please comment and we can reopen.

@teves-castro
Copy link

I was also having this problem when I noticed that when the project was added to the solution file it got added as hello\hello.fsproj instead of hello/hello.fsproj.
After manually changing this I was able to build from the sln.

@atlemann
Copy link

atlemann commented Aug 29, 2017

@rainersigwald I'm also getting this error on Ubuntu on dotnet build. dotnet restore works fine:

error MSB4025: The project file could not be loaded. Could not find file '***.fsproj.metaproj'

However, it is not consistent. I managed to get it working on one repo by recreating the .sln file using SDK2. However, trying to fix another repo the same way did not help. Manually switching from \ to / in the project path fixes it. But don't know if it will work on Windows anymore now.

So, for one solution \ in paths is ok, but for another it's not.

dotnet --info

.NET Command Line Tools (2.0.0)

Product Information:
Version: 2.0.0
Commit SHA-1 hash: cdcd192

Runtime Environment:
OS Name: ubuntu
OS Version: 16.04
OS Platform: Linux
RID: ubuntu.16.04-x64
Base Path: /usr/share/dotnet/sdk/2.0.0/

Microsoft .NET Core Shared Framework Host

Version : 2.0.0
Build : e8b8861ac7faf042c87a5c2f9f2d04c98b69f28d

@atlemann
Copy link

Hmm...something strange just happened. I tried to recreate the .sln file a second time using SDK2 and deleting the obj/ and bin/ folders in the project folder and then doing dotnet restore and dotnet build and now it works. I don't know why recreating the .sln file did not help the first time.

@Thorium
Copy link

Thorium commented Oct 19, 2017

I had a similar problem with Ubuntu 17.

rm -r -f obj
rm -r -f bin
sudo dotnet restore
sudo dotnet build

Works...

One possible reason could be that if you run dotnet restore without sudo it will fail silently on restore, not writing all the files but thinking that the restore was ok, and then when you try to build, there are not everything correct.

@forki
Copy link

forki commented Nov 20, 2017

yes deleting /obj during the build fixed it for me

@denizkanmaz
Copy link

I have the same issue when I add a NodeJS project in my solution.

Here is the build result

`[Stage_BlablaSolution] Running shell script

  • sudo dotnet clean BlablaSolution.sln
    Microsoft (R) Build Engine version 15.5.179.9764 for .NET Core
    Copyright (C) Microsoft Corporation. All rights reserved.

/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.Lib/Tascona.Lib.Utils/Tascona.Lib.Utils.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/ThirdFlemingo.Net/ThirdFlemingo.UnitTest/ThirdFlemingo.UnitTest.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/ThirdFlemingo.Net/ThirdFlemingo.Net/ThirdFlemingo.Net.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.Lib/Tascona.Lib.Data.Repo/Tascona.Lib.Data.Repo.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.Lib/Tascona.Lib.Business/Tascona.Lib.Business.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.Lib/Tascona.Lib.Data.DAL/Tascona.Lib.Data.DAL.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/Tascona.App.Presentation/Tascona.Presentation.Web/Tascona.Presentation.Web.csproj : warning NU1603: NEST 5.5.0 depends on Newtonsoft.Json (>= 10.0.0 && < 11.0.0) but Newtonsoft.Json 10.0.0 was not found. An approximate best match of Newtonsoft.Json 10.0.1 was resolved.
/var/lib/jenkins/workspace/Stage_BlablaSolution/NodejsConsoleApp1/NodejsConsoleApp1.njsproj.metaproj : error MSB4025: The project file could not be loaded. Could not find file '/var/lib/jenkins/workspace/Stage_BlablaSolution/NodejsConsoleApp1/NodejsConsoleApp1.njsproj.metaproj'.`

And here is the dotnet --info

.NET Command Line Tools (2.1.3)

Product Information:
 Version:            2.1.3
 Commit SHA-1 hash:  a0ca411ca5

Runtime Environment:
 OS Name:     ubuntu
 OS Version:  16.04
 OS Platform: Linux
 RID:         ubuntu.16.04-x64
 Base Path:   /usr/share/dotnet/sdk/2.1.3/

Microsoft .NET Core Shared Framework Host

  Version  : 2.0.4
  Build    : 7f262f453d8c8479b9af91d34c013b3aa05bc1ff

@berdon
Copy link

berdon commented Jan 24, 2018

I can reproduce this by attempting to dotnet publish a multi-project solution using WSL.

Porges added a commit to Porges/fsharp-hedgehog that referenced this issue Feb 7, 2018
@Porges
Copy link

Porges commented Feb 7, 2018

I just ran into this and can confirm that switching .sln project references from \ to / fixed it. How bizarre.

Here is my Travis build before: https://travis-ci.org/hedgehogqa/fsharp-hedgehog/builds/338361850
Here it is after: https://travis-ci.org/hedgehogqa/fsharp-hedgehog/builds/338379628

Porges added a commit to Porges/fsharp-hedgehog that referenced this issue Feb 7, 2018
@Robula
Copy link

Robula commented Feb 7, 2018

As above, switched \ to / in my .sln solved this.

@aBetterGamer
Copy link

But when you switch from \ to / in the .sln file things like SonarQube wont work.

SonarQube.Scanner.MSBuild.exe

@atagirov
Copy link

atagirov commented Feb 15, 2018

Switch from \ to / in the .sln solved for me, but i try another way and removed ProjectDependencies from .sln file for projects. You can find like this in your .sln file:
ProjectSection(ProjectDependencies) = postProject

after this .sln file successfull build with both variant of paths on unix and windows (i think, what \ is more correct variant).

@orient-man
Copy link

Upgraded on MacOS from 2.0.x to 2.1.4 and me too. Workaround with changing slash direction works though.

@takerukoushirou
Copy link

Ran into the same issue, C# projects only though. Also no ProjectDependencies section in my .sln. Changing all backslashes to forward slashes in project paths resolved the six errors if the form

error MSB3202: The project file "/path/to/project.csproj.metaproj" was not found.

when trying to dotnet build or dotnet test my solution with a total of 28 projects. Never had any issues with dotnet restore as well. Working on macOS with dotnet version 2.1.103.

@rainersigwald
Copy link
Member Author

@takerukoushirou Slash-direction problems should be fixed with #2963 which should be available in the .NET Core SDK versions 2.1.200 and 2.1.300, which have previews available.

@halcwb
Copy link

halcwb commented Apr 27, 2018

@rainersigwald
I now run 2.1.4 but the same problem here. Created a dotnetcore solution using the command line sdk. Edited the solution with VS2017. Tried to build it on macosx -> errors ;-)

/src/Informedica.GenUtils.Lib/Informedica.GenUtils.Lib.fsproj.metaproj : error MSB4025: The project file could not be loaded. Could not find file '/src/Informedica.GenUtils.Lib/Informedica.GenUtils.Lib.fsproj.metaproj'.

@rainersigwald
Copy link
Member Author

@halcwb What msbuild version are you using? dotnet msbuild -version. As I mention above, this is fixed in the .NET Core SDK 2.1.200 and 2.1.300, neither of which has hit final release yet.

Aaronontheweb added a commit to Aaronontheweb/akka.net that referenced this issue Mar 12, 2019
Aaronontheweb added a commit to akkadotnet/akka.net that referenced this issue May 16, 2019
… .NET 4.5.2 (#3668)

* migrated to 'dotnet test'

* added missing variable for detecing TeamCity

* added more targets for end-to-end testing and building

* fixed issue with dotnet test lockup for Akka.Cluster.Tests

* upgraded all core projects to standards

* fixed all major build issues thus far

* upgraded all contrib/cluster projects

* completed standardizing all projects

* fixed issue with Akka.DI.Core

* upgrade Linux to .NET Core 2.0 SDK

* further fixes to build.sh

* changed search location for MNTR assemblies

* upgraded MNTR to .NET 4.6.1

* fixed build.sh dotnet-install command

* fixed .NET Core test execution

* fixed issue with Akka.Remote.Tests.MultiNode outputting to wrong spot

* added channel to build.sh

* changed to wget

* fixed dotnet installer url

* skip API approvals on .NET Core

* fixed issue with MNTR NuGet packaging

* disabled FsCheck

* attempted to address Akka.Persistence memory leak

* migrated to 'dotnet test'

* added missing variable for detecing TeamCity

* added more targets for end-to-end testing and building

* fixed issue with dotnet test lockup for Akka.Cluster.Tests

* rebased on dev

* fixed all major build issues thus far

* upgraded all contrib/cluster projects

* completed standardizing all projects

* fixed issue with Akka.DI.Core

* upgrade Linux to .NET Core 2.0 SDK

* further fixes to build.sh

* changed search location for MNTR assemblies

* upgraded MNTR to .NET 4.6.1

* fixed build.sh dotnet-install command

* fixed .NET Core test execution

* fixed issue with Akka.Remote.Tests.MultiNode outputting to wrong spot

* added channel to build.sh

* changed to wget

* fixed dotnet installer url

* skip API approvals on .NET Core

* fixed issue with MNTR NuGet packaging

* disabled FsCheck

* attempted to address Akka.Persistence memory leak

* fixed issue with Akka.Streams tests

* standardized FluentAssertions version

* fixed compilation of TCK

* upgraded to .NET Core 2.1 SDK

* removed restore stage - no longer needed

* bumpe tests to .NET Core 2.1

* Revert "bumpe tests to .NET Core 2.1"

This reverts commit f76e09f.

* workaround dotnet/msbuild#2275 until .NET Core 2.1 migration

* Revert "upgraded to .NET Core 2.1 SDK"

This reverts commit b000b76.

* improved test error result handling

* Revert "Revert "upgraded to .NET Core 2.1 SDK""

This reverts commit 1b1a836.

* Revert "Revert "bumpe tests to .NET Core 2.1""

This reverts commit 175d6ca.

* moving onto .NET Standard 2.0

* standardized most test projects

* fixed common.props references

* fixed .NET Core 2.1 build systems

* fixed issue with packing MNTR

* fixed issue with single test failure stopping build

* fixed failure handling

* fixed issues with Akka.Streams specs

* fixed scan for incremental tests

* working on FsCheck standardization issues

* removed more net implicit standard junk

* cleaning up implicit package versions; bumped to JSON.NET 12.0.1

* fixed port bindings for Akka.Cluster.Tools and Akka.Cluster.Sharding so suites could theoretically run in parallel

* fixed more ports

* fixed compilation errors

* rolled back to Newtonsoft.Json 9.0.1

* disabled parallelization in Akka.Streams.Tests

* added xunit.runner.json

* Disabled xunit.runner.json for Akka.Streams.Tests

* added more debug logging to scriptedtest

* issue appears to be the 1ms deadline not being long enough on .NET Core - stream isn't even wired up yet

* fixed race condition with Bug2640Spec for #2640

needed to give the system more messages to process so we guarantee hitting all four dispatcher threads when running the test suite in parallel.

* updated API approvals

* fixed issue with Bug2640Spec again

No longer looking for an exact thread count since the CPU may not schedule it that. Instead, just ensure that all of the threads hit on the dispatcher shut down when the dispatcher is terminated.

* same fix as previous
madmonkey pushed a commit to madmonkey/akka.net that referenced this issue Jul 12, 2019
… .NET 4.5.2 (akkadotnet#3668)

* migrated to 'dotnet test'

* added missing variable for detecing TeamCity

* added more targets for end-to-end testing and building

* fixed issue with dotnet test lockup for Akka.Cluster.Tests

* upgraded all core projects to standards

* fixed all major build issues thus far

* upgraded all contrib/cluster projects

* completed standardizing all projects

* fixed issue with Akka.DI.Core

* upgrade Linux to .NET Core 2.0 SDK

* further fixes to build.sh

* changed search location for MNTR assemblies

* upgraded MNTR to .NET 4.6.1

* fixed build.sh dotnet-install command

* fixed .NET Core test execution

* fixed issue with Akka.Remote.Tests.MultiNode outputting to wrong spot

* added channel to build.sh

* changed to wget

* fixed dotnet installer url

* skip API approvals on .NET Core

* fixed issue with MNTR NuGet packaging

* disabled FsCheck

* attempted to address Akka.Persistence memory leak

* migrated to 'dotnet test'

* added missing variable for detecing TeamCity

* added more targets for end-to-end testing and building

* fixed issue with dotnet test lockup for Akka.Cluster.Tests

* rebased on dev

* fixed all major build issues thus far

* upgraded all contrib/cluster projects

* completed standardizing all projects

* fixed issue with Akka.DI.Core

* upgrade Linux to .NET Core 2.0 SDK

* further fixes to build.sh

* changed search location for MNTR assemblies

* upgraded MNTR to .NET 4.6.1

* fixed build.sh dotnet-install command

* fixed .NET Core test execution

* fixed issue with Akka.Remote.Tests.MultiNode outputting to wrong spot

* added channel to build.sh

* changed to wget

* fixed dotnet installer url

* skip API approvals on .NET Core

* fixed issue with MNTR NuGet packaging

* disabled FsCheck

* attempted to address Akka.Persistence memory leak

* fixed issue with Akka.Streams tests

* standardized FluentAssertions version

* fixed compilation of TCK

* upgraded to .NET Core 2.1 SDK

* removed restore stage - no longer needed

* bumpe tests to .NET Core 2.1

* Revert "bumpe tests to .NET Core 2.1"

This reverts commit f76e09f.

* workaround dotnet/msbuild#2275 until .NET Core 2.1 migration

* Revert "upgraded to .NET Core 2.1 SDK"

This reverts commit b000b76.

* improved test error result handling

* Revert "Revert "upgraded to .NET Core 2.1 SDK""

This reverts commit 1b1a836.

* Revert "Revert "bumpe tests to .NET Core 2.1""

This reverts commit 175d6ca.

* moving onto .NET Standard 2.0

* standardized most test projects

* fixed common.props references

* fixed .NET Core 2.1 build systems

* fixed issue with packing MNTR

* fixed issue with single test failure stopping build

* fixed failure handling

* fixed issues with Akka.Streams specs

* fixed scan for incremental tests

* working on FsCheck standardization issues

* removed more net implicit standard junk

* cleaning up implicit package versions; bumped to JSON.NET 12.0.1

* fixed port bindings for Akka.Cluster.Tools and Akka.Cluster.Sharding so suites could theoretically run in parallel

* fixed more ports

* fixed compilation errors

* rolled back to Newtonsoft.Json 9.0.1

* disabled parallelization in Akka.Streams.Tests

* added xunit.runner.json

* Disabled xunit.runner.json for Akka.Streams.Tests

* added more debug logging to scriptedtest

* issue appears to be the 1ms deadline not being long enough on .NET Core - stream isn't even wired up yet

* fixed race condition with Bug2640Spec for akkadotnet#2640

needed to give the system more messages to process so we guarantee hitting all four dispatcher threads when running the test suite in parallel.

* updated API approvals

* fixed issue with Bug2640Spec again

No longer looking for an exact thread count since the CPU may not schedule it that. Instead, just ensure that all of the threads hit on the dispatcher shut down when the dispatcher is terminated.

* same fix as previous
Aaronontheweb added a commit to Aaronontheweb/akka.net that referenced this issue Jul 30, 2019
… .NET 4.5.2 (akkadotnet#3668)

* migrated to 'dotnet test'

* added missing variable for detecing TeamCity

* added more targets for end-to-end testing and building

* fixed issue with dotnet test lockup for Akka.Cluster.Tests

* upgraded all core projects to standards

* fixed all major build issues thus far

* upgraded all contrib/cluster projects

* completed standardizing all projects

* fixed issue with Akka.DI.Core

* upgrade Linux to .NET Core 2.0 SDK

* further fixes to build.sh

* changed search location for MNTR assemblies

* upgraded MNTR to .NET 4.6.1

* fixed build.sh dotnet-install command

* fixed .NET Core test execution

* fixed issue with Akka.Remote.Tests.MultiNode outputting to wrong spot

* added channel to build.sh

* changed to wget

* fixed dotnet installer url

* skip API approvals on .NET Core

* fixed issue with MNTR NuGet packaging

* disabled FsCheck

* attempted to address Akka.Persistence memory leak

* migrated to 'dotnet test'

* added missing variable for detecing TeamCity

* added more targets for end-to-end testing and building

* fixed issue with dotnet test lockup for Akka.Cluster.Tests

* rebased on dev

* fixed all major build issues thus far

* upgraded all contrib/cluster projects

* completed standardizing all projects

* fixed issue with Akka.DI.Core

* upgrade Linux to .NET Core 2.0 SDK

* further fixes to build.sh

* changed search location for MNTR assemblies

* upgraded MNTR to .NET 4.6.1

* fixed build.sh dotnet-install command

* fixed .NET Core test execution

* fixed issue with Akka.Remote.Tests.MultiNode outputting to wrong spot

* added channel to build.sh

* changed to wget

* fixed dotnet installer url

* skip API approvals on .NET Core

* fixed issue with MNTR NuGet packaging

* disabled FsCheck

* attempted to address Akka.Persistence memory leak

* fixed issue with Akka.Streams tests

* standardized FluentAssertions version

* fixed compilation of TCK

* upgraded to .NET Core 2.1 SDK

* removed restore stage - no longer needed

* bumpe tests to .NET Core 2.1

* Revert "bumpe tests to .NET Core 2.1"

This reverts commit f76e09f.

* workaround dotnet/msbuild#2275 until .NET Core 2.1 migration

* Revert "upgraded to .NET Core 2.1 SDK"

This reverts commit b000b76.

* improved test error result handling

* Revert "Revert "upgraded to .NET Core 2.1 SDK""

This reverts commit 1b1a836.

* Revert "Revert "bumpe tests to .NET Core 2.1""

This reverts commit 175d6ca.

* moving onto .NET Standard 2.0

* standardized most test projects

* fixed common.props references

* fixed .NET Core 2.1 build systems

* fixed issue with packing MNTR

* fixed issue with single test failure stopping build

* fixed failure handling

* fixed issues with Akka.Streams specs

* fixed scan for incremental tests

* working on FsCheck standardization issues

* removed more net implicit standard junk

* cleaning up implicit package versions; bumped to JSON.NET 12.0.1

* fixed port bindings for Akka.Cluster.Tools and Akka.Cluster.Sharding so suites could theoretically run in parallel

* fixed more ports

* fixed compilation errors

* rolled back to Newtonsoft.Json 9.0.1

* disabled parallelization in Akka.Streams.Tests

* added xunit.runner.json

* Disabled xunit.runner.json for Akka.Streams.Tests

* added more debug logging to scriptedtest

* issue appears to be the 1ms deadline not being long enough on .NET Core - stream isn't even wired up yet

* fixed race condition with Bug2640Spec for akkadotnet#2640

needed to give the system more messages to process so we guarantee hitting all four dispatcher threads when running the test suite in parallel.

* updated API approvals

* fixed issue with Bug2640Spec again

No longer looking for an exact thread count since the CPU may not schedule it that. Instead, just ensure that all of the threads hit on the dispatcher shut down when the dispatcher is terminated.

* same fix as previous
@AR-May AR-May added the triaged label Feb 21, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests