I'm trying to understand the behavior of building fake assemblies. I'm able to add Fake Assembly in my unit test project, and it compiles into the FakesAssemblies folder locally.
However, I've been having issues lately where my dll's in FakesAssemblies-folder tries to reference an older version of the "QualityTools.Fakes"-reference. This happened after I've installed Update 5 (went from Update 3) of VS2013.
When cleaning the entire solution, the FakesAssemblies seems to be still there and not recompile.
The obvious workaround for this is to delete everything in the FakesAssemblies-folder whenever I need, but is this how it's meant to work?
You can add custom code to .csproj file (before the closing </Project> tag) to do it automatically:
<Target Name="AfterClean">
<RemoveDir Directories="$(ProjectDir)\FakesAssemblies" ContinueOnError="true" />
</Target>
Related
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
My csproj has the following lines:
<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">
<PropertyGroup>
<Deterministic>False</Deterministic>
<ItemGroup>
<ProjectReference Include="..\blah.Common\blah.Common.csproj" />
<ProjectReference Include="..\blah.Model\blah.Model.csproj" />
</ItemGroup>
The referenced projects build fine. However in the VS tree these two projects randomly disappear from the Dependencies tree and VS reports the references as missing and the build passes.
Reloading/rebuilding/cleaning/restarting/removing then adding the projects again in no particular order usually fixes it. Problem comes back after a legitimate build error crops up in another project.
I am using Resharper and VS2017
I have tried dotnet restore with no luck. Any ideas why this one particular project is constantly losing its references?
Edit: I just realised I incorrectly mentioned the build as FAILING. It does not fail and builds successfully, however my project is litered with red errors and warnings saying references are missing. After a successful build the red warnings/errors disappear then randomly come back again.
Sometimes the projects are literally missing from the references tree, other times they are visible. When right clicking "add reference" the project is already ticked however. Unloading the project and reloading or doing a full rebuild fixes the "Error" only for it to come back at some point.
Even though the "Error List" is filled with missing reference errors, a clean and full build produces no errors and creates a successful build.
Did you check the .NET framework version that these 3 projects are targeting?
Incompatibility between framework versions allows the reference to get added but results in missing references during build/run time. To validate if this is indeed the problem, you can check the warnings that Visual Studio produces while building the solution. An alternative way of finding the root cause of the problem, would be to add one of the projects as a DLL reference while keeping the other as a project reference. If the DLL reference doesn't work, it means there is some configuration mismatch between the source and target projects (e.g. .NET framework version). If the DLL version works, then it means Project References are broken, in which case you can check if path provided is correct.
I have two fairly straightforward C# projects: An executable that can build as either x86 or AnyCPU, which references (via <ProjectReference>) a DLL project that only has an AnyCPU configuration. This all works as expected within Visual Studio.
I am trying to build the x86 version of the executable project (and its dependencies) from the command line, with /p:Platform="x86". This causes the build of the DLL project to fail. (Whereas /p:Platform="AnyCPU" works, presumably because it is valid for both projects.)
The full command line I am using is:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\msbuild MyProject\MyProject.csproj /t:Build /p:Configuration="Release" /p:Platform="x86"
What are my options for getting this build to work from the command line? Preferably without modifying the DLL project at all, or modifying the projects in ways that interfere with using them normally in Visual Studio.
(The ultimate goal here is a batch file that can build a clean version of the project for distribution.)
Additional info:
Both projects have "Debug" and "Release" configurations. The executable project has "x86" and "AnyCPU" available under Platform. The DLL project has only "AnyCPU" available under Platform. The "Platform target" option matches the "Platform" in all cases. (There is no "Prefer 32-bit" option, as I am on VS2010.)
The error seems to be a compilation-related error ("no unsafe code allowed") in the DLL, which -- although I am not 100% sure -- seems to be because none of the <PropertyGroup> elements in the DLL project are being matched (due to Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' " etc) that would specify necessary parameters for compilation (eg AllowUnsafeBlocks and DefineConstants).
Answering my own question... First of all, MSBuild can build solution files. This does exactly what you'd expect:
msbuild MySolution.sln /p:Configuration="Release" /p:Platform="x86"
The result is an x86 executable with an AnyCPU DLL (as the solution specifies).
There are a few people out on the internet suggesting that its behaviour is not a perfect match for Visual Studio in some obscure cases. But it seems to work just fine for my purposes. (I think they were having issues with the order things get built in.)
I knew that MSBuild could build a solution file, but -- oops -- I neglected to test it on my simple reproduction case, after it failed on the more complex thing I'm working on.
The above, alone, isn't enough for a fully satisfying answer, particularly if there is a need to customise things. The way MSBuild builds solution files is to create a dummy project file, based on the solution file. This can be inspected by first setting an environment variable like so:
set MSBuildEmitSolution=true
This will emit the dummy project file next to the solution file, which can then be inspected.
I haven't completely analysed what it is doing, but it looks fairly straightforwardly like it is using the <MSBuild> task with the Projects parameter that is itself passing in the solution-specified Configuration and Platform appropriate for each project. According to the documentation it seems to be using the ones specified in AdditionalProperties. (This also seems useful to know.)
For reference, here is some relevant code extracted from the generated project file:
<Target Name="Build" Outputs="#(CollectedBuildOutput)">
<MSBuild Projects="#(ProjectReference)" BuildInParallel="True" Properties="BuildingSolutionFile=true; CurrentSolutionConfigurationContents=$(CurrentSolutionConfigurationContents); SolutionDir=$(SolutionDir); SolutionExt=$(SolutionExt); SolutionFileName=$(SolutionFileName); SolutionName=$(SolutionName); SolutionPath=$(SolutionPath)" SkipNonexistentProjects="%(ProjectReference.SkipNonexistentProjects)">
<Output TaskParameter="TargetOutputs" ItemName="CollectedBuildOutput" />
</MSBuild>
</Target>
Where #(ProjectReference) is grabbing data from:
<ItemGroup>
<ProjectReference Include="X:\Solution\MyProject\MyProject.csproj">
<ToolsVersion>
</ToolsVersion>
<SkipNonexistentProjects>False</SkipNonexistentProjects>
<AdditionalProperties>Configuration=Release; Platform=x86; VisualStudioVersion=10.0</AdditionalProperties>
<Configuration>Release</Configuration>
<Platform>x86</Platform>
</ProjectReference>
<ProjectReference Include="X:\Solution\DLLProject\DLLProject.csproj">
<ToolsVersion>
</ToolsVersion>
<SkipNonexistentProjects>False</SkipNonexistentProjects>
<AdditionalProperties>Configuration=Release; Platform=AnyCPU; VisualStudioVersion=10.0</AdditionalProperties>
<Configuration>Release</Configuration>
<Platform>AnyCPU</Platform>
</ProjectReference>
</ItemGroup>
(Note the different AdditionalProperties.)
I'm using Visual Studio Code for a .NET Core Project.
I have an ASP.NET Core Project for which i want to create a separate unit tests project, i created a sub folder and ran
dotnet new xunit
dotnet restore
When i tried to run it from the cli "dotnet build" "dotnet run" it ran successfully, however in visual studio, it says that it can't find the namespace Xunit
This is very strange because Visual Studio code has worked fine for me so far, it never had problem with dependencies, it only has this problem with Xunit.
Anyone familiar with this issue?
I had the same issue. It was solved by typing "Restart Omnisharp" in the Command Palette.
Adding the xunit reference to the root csproj is likely undesirable.
The Issue
The idea of having tests in a separate csproj is that they and their dependencies won't be included in the main project. Adding xunit to the root csproj will however cause the main project to reference xunit. Depending on how the product is bundled, this will cause the xunit dlls and all the dlls it depends on to be included unnecessarily.
Unfortunately, Omnisharp has an issue with nested csproj. It appears the root csproj will claim all source files in all subdirectories, even if there are nested csproj. This causes the missing reference error.
The Solution
Do not nest csproj. Note how Microsoft's xunit setup guide puts the main csproj and its tests csproj into different subdirectories of the sln.
I first ran into this error as well and after restructuring the project to not nest csproj, the error was resolved; with only the tests csproj referencing xunit.
I tried opening the test project directly with vscode (instead of opening the root project that contains the test project in a sub folder) and now vscode recognizes Xunit.
I then opened the root project with vscode again, added Xunit to the root project's csproj file, ran "dotnet restore" in the root project and now Xunit is recognized in the test project.
The thing is that vscode (or is it Omnisharp? i'm not sure) probably looks only at the root csproj file and ignores any csproj file that happens to be in a sub folder.
Prelude
None of the above worked for me.
Turns out I should have checked my notes from before, as this has been a recurring issue here with a project that uses Xunit:
Make sure all installed Xunit.xxxxxxxxx packages have the EXACT SAME version.
The problem occurs while/after having updated my NuGet packages automatically, which will, at the time of writing, install Xunit 2.4.1 (and several other xunit packages at version 2.4.1) plus xunit.runner.visualstudio at version 2.4.3 (!)
While nothing untoward is reported during this NuGet update, the result is a permanently failing build, where Fact and Assert are suddenly unknown, e.g.
Error CS0246: The type or namespace name 'Fact' could not be found (are you missing a using directive or an assembly reference?) Imazen.Test.Webp
The fix
What did work out for me was to go and revert that xunit.runner.visualstudio update, re-installing 2.4.1.
BTW, in Visual Studio, this would then look something like this (after the revert/re-install):
Note that the package manager there is hinting that an update is available and as soon as you apply that 2.4.3 update again, in any way, you're back to square one: a curiously failing build.
The key to the solution is to have all installed xunit packages with the same version. -- if only a few have updates available on NuGet, wait until all xunit packages are available for that same version.
Postscript
Don't know why this is so finicky, as I've only observed this brittle behaviour with xunit.*, but this is what has worked earlier this year (I had forgotten) and now had happen to me again, with the same outcome: the mandatory revert of a NuGet xunit package update.
#areller's solution solved my issue. I just want to expand on his answer to provide some sample code, in case there are other people who doesn't know exactly what to do (especially if you just started on C# like I did).
The Issue
First, I followed instructions here to start writing unit tests for a .NET Core application:
https://learn.microsoft.com/en-gb/dotnet/core/testing/unit-testing-with-dotnet-test
Then I encountered the same issue mentioned by OP.
Solution
First, I tried Claus' solution by restarting OmniSharp, but it doesn't fix the issue.
Then, following #areller's suggestion, I found these lines in Tests.csproj:
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.7.0" />
<PackageReference Include="xunit" Version="2.3.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.3.1" />
<DotNetCliToolReference Include="dotnet-xunit" Version="2.3.1" />
</ItemGroup>
I copied that, and pasted in my root directory's .csproj file, so the root .csproj looks like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.1</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Microsoft.NET.Test.Sdk" Version="15.7.0" />
<PackageReference Include="xunit" Version="2.3.1" />
<PackageReference Include="xunit.runner.visualstudio" Version="2.3.1" />
<DotNetCliToolReference Include="dotnet-xunit" Version="2.3.1" />
</ItemGroup>
</Project>
After that, VS Code asks me to restore. The VS Code dialog came with a "Restore" button; I clicked on that; several seconds later the issue is gone.
Good luck!
I had the same issue. I installed xunit.extensibility.core (2.4.1) for my .Net 5 solution and it solved the issue. xunit.runner.visualstudio (2.4.3) was already present.
This is a weird one.
I have Visual Studio 2013 installed. If I create a new project, Visual Studio immediately complains that it cannot find any of the references:
The project does however compile and run correctly, even though there are warnings in the error list:
If I look at the properties of any of these references, their paths are empty. If I load an existing project, Visual Studio can find its references and doesn't complain, even though it is targeting the same version of the .Net framework as the broken project (I've even had them both in the same solution with the same behaviour).
How can I fix this, and what could have caused it? Any suggestions welcome, as it is baffling me.
With thanks to icemanind, I have the answer.
I closed Visual Studio, deleted the following directories and everything is now working as normal again:
C:\Users\<username>\AppData\Local\Microsoft\VisualStudio\12.0
C:\Users\<username>\AppData\Roaming\Microsoft\VisualStudio\12.0
I faced this problem, and I solved it by closing visual studio, reopening visual studio, cleaning and rebuilding the solution. This worked for me. On some other posts, I have read the replies and most of users solved the problem by following this way.
Another possibility is that the target .NET Framework version of the class library is higher than that of the project.
This happens to me from time to time and I always suspect VS corruption, but it always turns out to be user error. It typically happens when I add a new project to a solution and try to reference earlier projects in the newly added project. In this case and in general, you can only add a reference if it targets the same or earlier .NET Framework version. In my case, inconsistent target framework versions caused the project to not recognize references and not allow compilation. Double checking consistency or proper target framework versions solved this problem for me.
I had a problem with an existing project, and by creating a new one and comparing the csproj files I had to add missing import lines like those: one at the beginning of the project element and one at the end.
<Project ToolsVersion="12.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Import Project="$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props" Condition="Exists('$(MSBuildExtensionsPath)\$(MSBuildToolsVersion)\Microsoft.Common.props')" />
...
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
</Project>
I recently had this happen in VS 2017. I had done some refactoring on a project where the csproj file had moved, then cloned the repository onto a new machine. The csProj file had multiple locations for the .projects directory. For example:
<Import Project="packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="packages\Microsoft.Net.Compilers.1.2.1\build\Microsoft.Net.Compilers.props" Condition="Exists('packages\Microsoft.Net.Compilers.1.2.1\build\Microsoft.Net.Compilers.props')" />
<Import Project=".\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('.\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.1\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project=".\packages\Microsoft.Net.Compilers.1.2.1\build\Microsoft.Net.Compilers.props" Condition="Exists('.\packages\Microsoft.Net.Compilers.1.2.1\build\Microsoft.Net.Compilers.props')" />
There were additional relative path errors below in the Error tags as well.
I looked for any places where I had duplicated, incorrect package relative paths, and removed the incorrect ones.
This caused it to build for me.
Good luck out there!
-Mezz
I had a similar issue with vs2015. It turns out a file was added twice to the .csproj
Deleting the duplicated line solved it
In a most cases you need:
Unload Project
Reload Project with dependecies
Rebuild solution