We Keep Coding

MSBuild - one Package Reference interferes with loading a separate Task

Using MSBuild, the following builds and works fine:
<PackageReference Include="Publicise.MSBuild.Task" Version="1.3.0"/>
<Target Name="Publicise" BeforeTargets="BeforeBuild">
<Publicise
AssemblyPath="..."
OutputPath="../"/>
</Target>
However, when I add another Package Reference (changing nothing else), it encounters errors on build:
<PackageReference Include="Publicise.MSBuild.Task" Version="1.3.0"/>
<PackageReference Include="ILRepack.MSBuild.Task" Version="2.0.13"/>
This results in error MSB4062:
The "Publicise" task could not be loaded from the assembly ...\ILRepack.MSBuild.Task.dll. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
Why is something completely separate preventing the task from being properly found, and how can I fix this?

The issue is caused by these two msbuild task nuget packages accidentally.
And since you have installed the ILRepack.MSBuild.Task nuget package at the end. And the PackageReference node of ILRepack.MSBuild.Task is akways at the end. So $(TaskAssembly) is always loads from ILRepack.MSBuild.Task nuget package and the value from publicise.msbuild.task is being covered. And the issue The "Publicise" task could not be loaded from the assembly ILRepack.MSBuild.Task.dll makes sense.
C:\Users\xxx\.nuget\packages\publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props
C:\Users\xxx\.nuget\packages\ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props
Also, when you project loads the nuget package, you can check under C:\xxx\source\repos\xxx(project_name)\xxx(project_name)\obj\xxx.csproj.nuget.g.props:
Loading the ILRepack.MSBuild.Task.props is always at the end and $(TaskAssembly) is always from ilrepack.msbuild.task due to being overwritten by the later installed package.
The error Publicise task(should be from publicise.msbuild.task) from ilrepack.msbuild.task could be understood.
Solution
So you should make publicise.msbuild.task at the end.
Solution 1)
open C:\xxx\source\repos\xxx(project_name)\xxx(project_name)\obj\xxx.csproj.nuget.g.props file,
modify like this:
<ImportGroup Condition=" '$(ExcludeRestorePackageImports)' != 'true' ">
<Import Project="$(NuGetPackageRoot)ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props" Condition="Exists('$(NuGetPackageRoot)ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props')" />
<Import Project="$(NuGetPackageRoot)publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props" Condition="Exists('$(NuGetPackageRoot)publicise.msbuild.task\1.3.0\build\Publicise.MSBuild.Task.props')" />
</ImportGroup>
make Publicise.MSBuild.Task.props at the buttom.
Then, save the changes and then click Build button rather than Rebuild button to test again.
Solution 2)
downgrade ILRepack.MSBuild.Task nuget package to version 2.0.0.
===============================
Update 1
Thanks for sharing your opinion about the workaround. Since these two nuget packages have to be used in your project, so these two solutions might not be very useful.
The error, conflict is caused by the author of the nuget packages and incidentally, you're using the same TaskAssembly property from these two nuget packages at the same time.
TreatAsLocalProperty="TaskAssembly" will not solve the issue. <packages_id>.props files from the nuget packages are still embedded in the project's CSPROj file. Whether the fields are the same as TaskAssembly or will conflict.
The better solution is that you should rename one of the TaskAssembly of the nuget packages to another, which would not cause conflict.
1) Open C:\Users\xxx\.nuget\packages\ilrepack.msbuild.task\2.0.13\build\ILRepack.MSBuild.Task.props file:
change TaskAssembly property to another like TaskAssembly_copy:

NUnit tests not running on simple examples [duplicate]

In spite of adding NUnit from NuGet to an existing .Net Core project, no unit tests are being shown in the Test Pad.
Note: I posted these images as links because I have too low of a reputation to post images. What's up with that?
Project > Add NuGet Packages...
Selected NUnit Package (3.11.0) and clicked "Add Package"
Checked to see if added to solution
Created a new empty class file within the solution
Added tests to this class
No tests show up in the test pad
I've tried restarting Visual Studio and reinstalling the package.
I've also tried deleting the Project/obj directory -- still no luck.
using NUnit.Framework;
namespace ExampleLib
{
[TestFixture]
public class ExampleTestFixture
{
[Test]
public void ExampleTest()
{
Assert.AreEqual(2, 2);
}
}
}
Expected: Tests fill the Unit Test pad
Actual: Empty test pad.

There are multiple requirements of that project, so that VS for Mac can identify and execute the test cases.
The project must be a console application of .NET Core.
The project must have a reference of Microsoft.NET.Test.Sdk (required by VSTest infrastructure).
The project must have a reference of NUnit.
The project must have a reference of NUnit3TestAdapter (required by VSTest infrastructure).
Example,
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.2</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="NUnit" Version="3.11.0" />
<PackageReference Include="NUnit3TestAdapter" Version="3.12.0" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.9.0" />
</ItemGroup>
</Project>
Note that VS for Windows and VS for Mac (and JetBrains Rider) all use VSTest for unit testing, so this setup works for all such IDEs.
Also note that if you didn't create this console project from dotnet new nunit, but a normal console application template, you need to manually delete the Main method.

The NuGet package only allows you to use the NUnit framework to write tests. In other words, it's like adding references to the NUnit DLLs.
You need to install the adapter to see the tests.

As lex-li comments, you should install the nuget version of the adapter (https://www.nuget.org/packages/NUnit3TestAdapter/3.12.0).
You install this into your solution, preferably for all test projects.
(The adapter on the marketplace is the vsix adapter, which can be installed into VS itself - but this practice is not recommended and as you points out, doesn't even seem to work for Mac Community version.)

Specflow is not executing tests in Visual Studio 2019

I have a very weird behavior with Specflow that only applies to one team member. Everyone else have no issue what so ever.
The VS2019 testrunner is correctly displaying all specflow tests, but when "Running all tests" none of the tests gets executed but have the information "no source available". Specflow is generating all cs files correctly.
I tried to create a completly new solution with one unit test project in it, added specflow to it, created a feature, generated the steps and run all tests. Everything worked as expected, the test was executed and was successful. Then I added this new csproj to the other solution where the tests are not exectued. Strangly the "new test" didn't work in the old solution either.
When someone else of the project team is cloning our repository, installing specflow everything works fine for them. It is only this one machine in this one solution. I already tried to reinstall VS2019. We checked that every project in the solution has the same target platform, we tried to delete some %TEMP% files but nothing worked so far.
NuGet packages:
SpecFlow v3.0.225
SpecFlow.MsTest v3.0.225
SpecFlow.Tools.MsBuild.Generation v3.0.225

I had the same issue as you with:
VS 2019 v16.6.2
SpecFlow v3.30.2
SpecFlow.Tools.MsBuild.Generation v3.3.30
SpecRun.Runner v3.3.14
SpecRun.Specflow.3-3-0 v3.3.14
MSTest.TestAdapter v2.1.2
MSTest.TestFramework v2.1.2
I tried many tricks from this forum and Github SpecFlow support and none worked.
When I looked at the log file, on the TestResults folder, I saw something interesting:
I basically logged on that link (with the same account that is logged in VS) and the tests start to run.
Hope that solves your business mate. I know these things drives anyone mad.

I had a similar problem with a SpecFlow Project using MSTest as unit test provider, the tests were visible in the Test-Explorer but running them had no effect. I was able to solve my problem by installing the NuGet package MSTest.TestFramework.

Same problem, find the .sln where the acceptance tests reside and delete the contents of the bin folder completely. Rebuild your solution and run your acceptance tests.

I had a similar issue in VS 2022 using .NET 6. I managed to get it working for NUnit with the following Nuget packages.
<PackageReference Include="FluentAssertions" Version="6.8.0" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.3.2" />
<PackageReference Include="NUnit" Version="3.13.3" />
<PackageReference Include="NUnit3TestAdapter" Version="4.2.1" />
<PackageReference Include="Selenium.Support" Version="4.5.1" />
<PackageReference Include="Selenium.WebDriver" Version="4.5.1" />
<PackageReference Include="SpecFlow" Version="3.9.74" />
<PackageReference Include="SpecFlow.NUnit" Version="3.9.74" />
<PackageReference Include="SpecFlow.Plus.LivingDocPlugin" Version="3.9.57" />
Note the key package to get the tests to actually run in the Test Exlporer was
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="17.3.2" />

.NET Core - Nuget Pack of UniTest Project shows warning "The assembly is not inside the 'lib' folder"

I'm trying to pack a UnitTest project as a Nuget package and I always get the following warning(s) if I build my project:
The assembly
'content\SpecFlow.MSDependencyInjection.SpecFlowPlugin.dll' is not
inside the 'lib' folder and hence it won't be added as a reference
when the package is installed into a project. Move it into the 'lib'
folder if it needs to be referenced.
My csproj file looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<GeneratePackageOnBuild>true</GeneratePackageOnBuild>
<Version>0.1.0</Version>
<IsPackable>true</IsPackable>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.Extensions.Http" Version="2.2.0" />
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="16.0.1" />
<PackageReference Include="MSTest.TestAdapter" Version="1.4.0" />
<PackageReference Include="MSTest.TestFramework" Version="1.4.0" />
<PackageReference Include="SpecFlow" Version="3.0.188" />
<PackageReference Include="SpecFlow.MSDependencyInjection.SpecFlowPlugin" Version="1.0.2" />
<PackageReference Include="SpecFlow.MsTest" Version="3.0.188" />
<PackageReference Include="SpecFlow.Tools.MsBuild.Generation" Version="3.0.188" />
</ItemGroup>
</Project>
The error still appears if I copy the files into the lib folder of the Nuget package. I'm at a loss what I need to change for this warning to disappear. To be frank I'm not even sure why it appears in the first place because I have a different project that works fine without this error.
Update 1:
After the detailed answer from #zivkan I changed my project structure so it is not a UnitTest project anymore.
Sadly the errors still appear if my project is a class library...
Screenshot with all Nuget-Packages that I need for my project to work
If I only add my own Nuget-Package that consists of two dependencies (Microsoft.Extensions.DependencyInjection and SpecFlow) it still produces this error but the two dependencies in this Nuget-Package don't. To me this seems to be a problem with the Nuget-Packages...

I'm not 100% sure, but my guess is that since with SDK style csproj files, when you build, only your assembly's dll is normally written to the output directory. When you run a non-test netcoreapp, the dotnet cli looks at what project references and nuget references you have, and configures the assembly loader to load from their "original" locations, rather than having all the assemblies copied to your app's bin folder. Perhaps the unit test framework doesn't support loading assemblies in this way and creates Content items out of each dll, which tells the build step to copy the content (in this case dlls) into the output directory (bin\$(Configuration)\$(TargetFramework)). Therefore, when you run unit tests, the unit test framework has all the required assemblies in the single directory, whereas that's normally not true for non-test projects.
Next you need to understand that when NuGet packs a project, it looks for MSBuild items of the type Content, and puts copies of them in the nupkg's content and contentFiles directories. Due to how NuGet works, only dlls in the lib\ or ref\ directories within the nupkg are given to the compiler, therefore any dlls you have a content directory will not be passed to the compiler, so your project that references this nupkg cannot use classes in those dlls. This is not how people usually intend to use NuGet packages and therefore NuGet generates a warning.
So, I believe the reason you're getting this warning is because you're packing a project type that is not intended to be packable. The project type does some uncommon things in order to work, which triggers NuGet warnings because typically when this uncommon thing is done, it's a mistake.
I believe this to be a case of a XY problem. I assume you're packing a unit test project because you want to share some utility code useful for tests, maybe some mocks or object initialisation code. In this case, I recommend you create a new classlib project, put your shared code in there, leaving all your test cases in your netcoreapp test project, even if it's nothing more than a single method call into the classlib. This way you can pack and share the classlib without warnings. Packing a unit test seems unusual and it would be interesting to discuss why you want to do this, what problem do you intend to solve and if packing a test is really the best way to achieve it. Unfortunately Stack Overflow isn't a good place to have discussions and is often actively discouraged.

perhaps you have missed a file, please follow this link for full details : https://learn.microsoft.com/en-us/nuget/create-packages/creating-a-package#Package_Conventions

Using Selenium WebDriver in library csproj with .NET Core

I'm trying to put together a web-scraping app, using Selenium and .NET Core, but I'm having trouble getting my WebDriver exes to be found.
I have one .csproj that will run the API for the project, which calls out to (amongst others) another .csproj that will handle the webscraping.
All are in a single .sln, and all are running .NET Core 2.1
In the scraping proj, I've nuget-installed Selenium.WebDriver and Selenium.WebDriver.ChromeDriver.
I've created an endpoint in the API, which calls out to the scraping project, and runs a method that attempts to invoke new ChromeDriver(). It doesn't work :( Specifically, I get:
The chromedriver.exe file does not exist in the current directory or in a directory on the PATH environment variable. The driver can be downloaded at ... <url>
Seems fairly clear (although it dissappointingly doesn't tell you what "current directory" means. I'll be submitting a PR for that imminently)
By observing changes during a rebuild, and other research online, I see that:
All the dlls and exes from the nuget packages are stored in the Global Nuget cache, rather than a nuget packages folder in the solution directory.
This appears to be expected behaviour: "Bug" raised in dotnet Std; MSDN migration docs.
The chromedriver.exe appears to get copied to <solutionFolder>\<ScrapingProjectFolder>\bin\Debug\chromeDriver.exe.
I assume that this is what the ChromeDriver Nuget package does; certainly I haven't configured it myself.
This superficially feels like a reasonable thing for that ChromeDriver package to be doing as an attempt at "install this to make new ChromeDriver() JustWork."
Digging into the WebDriver codebase, reveals that the "currentDirectory" that it's looking at is "the location of WebDriver.dll".
In my case, that's "<globalNugetPackagesCache>\selenium.webdriver\3.141.0\lib\netstandard2.0"
It doesn't seem like I should be trying to get the chromedriver.exe to end up in this folder - copying it into a different package's global cache seems wrong? (Do people agree?)
This article seems to have reached broadly the same conclusion and says that the solution is to invoke the driver as:
new ChromeDriver(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location))
Unfortunately, that path takes me to <solutionFolder>\<APIProjectFolder>\bin\Debug\<ScrapingProjectFolder>.dll, because the dll gets copied over the the API project's folder.
A couple of solutions occur to me, none of which really appeal:
I could install Selenium.WebDriver.ChromeDriver into the API project.
Eww... the API project doesn't know about WebDriver or Selenium, and now the Scraping project doesn't have the driver exe.
I could manually explictly copy the exe into the right place.
Doesn't really feel right, and feels fragile. I suspect this will make deployment painful.
I could manually point the ChromeDriver constructor to a hard-coded path, that I just happen to know contains the current exe.
Seems similar to the above; though not quite as bad.
??? Is there some way to make all the DLLs etc. of a project get compiled into a single common folder? ???
Is there a good, non-hacky way to solve this problem. Which will result in a git repo that JustWorks, and is going to be relatively painless to deploy to a server in the future?
Are any of the things I've described above wrong, or mis-configured?

From what I understand you have an API project that depends on a Scraping project.
Scraping.csproj:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<LangVersion>7.2</LangVersion>
<PublishChromeDriver>true</PublishChromeDriver>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Selenium.WebDriver" Version="3.141.0" />
<PackageReference Include="Selenium.WebDriver.ChromeDriver" Version="2.46.0" />
</ItemGroup>
</Project>
API.csproj:
<Project Sdk="Microsoft.NET.Sdk">
<ItemGroup>
<ProjectReference Include="..\Scraping\Scraping.csproj" />
</ItemGroup>
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<LangVersion>7.2</LangVersion>
</PropertyGroup>
</Project>
The trick is adding <PublishChromeDriver>true</PublishChromeDriver> to the transitive project to make it publish the chromedriver when running dotnet publish API.csproj The ChromeDriver package has custom build targets in the NuGet package so it is custom.
You can now use
new ChromeDriver(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location));
and dotnet run API.csproj

Please correct me if I'm wrong. You have some kind of Class Library that has reference to Selenium and you would like to use ChromeDriver.exe but you are getting an error that it cannot be found under the following location. This is fairly simple.
Currently you are referencing Class Library lets say Foo to API. Your Assembly Location will point to API bin location, whereas chromedriver.exe is located under Class library bin.
If this is the case the only thing you would have to do is copy following chromedriver.exe to final bin directory which is API.
Add following Post Build Event to your API project to copy chromedriver:
<Target Name="PostBuild" AfterTargets="PostBuildEvent">
<Exec Command="copy $(SolutionDir)\ClassLibrary\bin\Debug\netstandard2.0\chromedriver.exe $(TargetDir)" />
</Target>
This will copy your chromedriver.exe to API bin. Later while initializing ChromeDriver use:
var options = new ChromeOptions();
var service = ChromeDriverService.CreateDefaultService(AppDomain.CurrentDomain.BaseDirectory);
WebDriver = new ChromeDriver(service, options);
While AppDomain.CurrentDomain.BaseDirectory will point to your API bin directory.