Just like this guy, I didn't create a unit test project for my MVC 4 project when it was first created. Now I want to go back and add one.
To that end, I created a new Unit Test Project.
Now, I right-click on a private method in one of my controllers, select Create Unit Tests, and get a popup dialog asserting:
Unit Test Generation Error: The following error was encountered while reading module
'My.Project': Could not resolve the type reference: [System.Web.Mvc, Version 3.0.0.0,
Culture=neutral, PublicKeyToken={why doesn't MS support cut and
paste??}]System.Web.Mvc.AllowAnonymousAttribute.
AllowAnonymousAttribute is new to MVC 4. Why is the Unit Test Generator trying to resolve against the MVC 3 assembly though?
My.Project compiles and runs just fine, AllowAnonymousAttribute and all, and clearly is reverencing System.Web.Mvc, Version 4.0.0.0.
UPDATE
MyMvc.csproj contains
<Reference Include="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\packages\AspNetMvc.4.0.20126.16343\lib\net40\System.Web.Mvc.dll</HintPath>
</Reference>
The DLL at HintPath is confirmed to be version 4.0.0.0
MyMvc.Test.csproj contains
<Reference Include="System.Web.Mvc, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
This is no longer an issue in VS2012.
VS2012 no longer supports the add unit test wizard. Manually added unit tests work fine.
Download Resharper (there's a free 30 day trail) and press alt+enter. It will automatically add what is needed.
Related
I have a package which should only be a compile-time dependency, i.e.
included in the build but not part of output. Like "CopyLocal=false" works in non-sdk projects.
I tried <ExcludeAssets>runtime</ExcludeAssets> on PackageReference which sort of works but not consistently. Sometimes the dependency is also excluded from the build. (reopening the solution fixes it sometimes. It is all very random)
So I have 2 questions:
Is excluding "runtime" supposed to also exclude it from build or is that a bug?
Is there another way to include a dependency in the build but exclude it from runtime.
Background:
I have two types of dependencies where I need this functionality. One is a licensed product where a "generic" version of the assembly is used for the build. Similar to reference assemblies i Visual Studio. The real assembly is available in the production environment.
The second one is an assembly containing only constants. It is not needed at runtime since it is not used.
Excluding the constant-only assembly is just cosmetic but shipping the "generic" assemblies causes problems on e.g. updates where they can overwrite the real ones.
I have a Xamarin binding, and another one which depends on the first. In the second binding the dependency to the first requires the dependency to be published on nuget. However, as both are updated together, it's not possible to build the second binding without publishing the first.
Ideally what I'd like to do is depend on the first package locally when building, but in the package .nuspec depend on the nuget package. As the first package will be published first, when the second package is published the dependency can be satisfied. Is this possible?
Do they need to live apart? Couldn't you have both projects live in the same solution? This way you could build them together, then package these two libraries separately afterwards.
Alternatively, you could create a local repository, which is just a folder where you put in your dependencies, and you can simply point to that folder as a NuGet repository. You can configure that through VS, or you can create a NuGet.config in the root of the repository and add an entry looking something like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="Local Packages" value="path/on/disk" />
</packageSources>
</configuration>
This should automatically be picked up by NuGet and it will try to restore packages from here too.
I'm trying to upgrade a huge project from core 1.0 to 2.2. I decided to do this through creating new project from scratch and just moving there all files from existing project. I did that, fixed all errors related to usage of inappropriate packages, old syntax etc.
Now I get the login page when running project, but after actually logging in i get TypeLoadException.
"TypeLoadException: Could not load type 'System.ComponentModel.DataAnnotations.AssociatedMetadataTypeTypeDescriptionProvider' from assembly 'System.ComponentModel.DataAnnotations, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'."
This question is similar to one described here.
When using "legacy"-style .csproj project files we have a separate packages.config file where all dependencies are listed, including transitive ones. This enables a use case when one installs a package with dependencies and then decides which transitive dependencies can be manually updated. So, the benefits are:
Dependencies are easily identifiable due to presence of a flat list
Fine-grain control over all dependency versions
E.g., after installing Autofac.WebApi2.Owin from NuGet, we have a picture like this:
Transitive dependencies which are clearly viewable can be manually updated very easily.
When using the new Sdk-style .csproj projects NuGet references are added as <PackageReference/> to the project file itself and transitive dependencies are referenced by MSBuild silently:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>net462</TargetFramework>
</PropertyGroup>
<ItemGroup>
<PackageReference Include="Autofac.WebApi2.Owin" Version="4.0.0" />
</ItemGroup>
</Project>
So, to update transitive dependencies, one would have to
Identify them (e.g. via obj/project.assets.json)
Add all of them explicitly to the project
Perform updates
And this has to be done after each update and for every (!) transitive dependency in the project which is clearly almost impossible.
Possible resolutions:
Adding transitive dependencies to the project automatically
Show transitive dependency updates in NuGet GUI
Unfortunately, no such feature was found in the documentation.
So, is there an easy way to get the best from two worlds?
Not possible at the moment but a discussion is open on Github.
So, is there an easy way to get the best from two worlds?
I think NuGet already have an easy way to get the best from two worlds.
When using the new Sdk-style .csproj projects, you will notice that there is a tree structure of transitive dependencies in the Reference:
With this structure, we can not only get presence of a flat list can also clearly know the specific dependencies between packages. In the "legacy"-style .csproj, we could to know the flat list, but we could not know the specific dependencies between each package. We need select each package, then check it`s Dependencies. This is very inconvenient.
Besides, we generally do not go over the package itself and update its dependencies directly, this will bring a lot of conflict between dependencies. When you using the new Sdk-style, NuGet hides all dependencies of each package, so that the NuGet Package Manager UI and project file .csproj looks very simple.
If you still want to update one of dependence individually, you can install it, nuget will prompt you, you are update package from version 1 to version 2:like, Autofac:
In this case, you can update dependencies not referenced directly as PackageReference via NuGet.
For more detail info, you can refer to below blog:
https://blog.nuget.org/20170316/NuGet-now-fully-integrated-into-MSBuild.html
The ability to control transitive package reference updates is now being tracked in https://github.com/NuGet/Home/issues/5553
Before ASP.Net Core:
I create a MVC site and two class libraries in one solution. Let's say the project names are MVC, Lib1 and Lib2.
I add references as follows: MVC references Lib1, Lib1 references Lib2.
With this reference structure, MVC cannot access classes in the Lib2 project, which is as expected and what I want.
The same project and reference structure in ASP.Net Core: MVC can access classes in Lib2. Looking at the MVC/References node in the Solution Explorer in Visual studio, you can see MVC/References/DNX 4.5.1/Lib1 - so far so good (I did add a reference to Lib1 from MVC) - but then I can expand the Lib1 node, and will see Lib2 under it. End result: MVC can access Lib2 classes via a reference chain.
I presume this behaviour is by design, but then how can I achieve the old behaviour? I do not want developers to be able to access Lib2 classes from MVC.
Yeah, this is now a feature in .NET Core. Read more from this SO answer.
BUT you can hide Lib2 from your MVC csproj using PrivateAssets attribute on your ProjectReference:
in your Lib1.csproj:
<ItemGroup>
<ProjectReference Include="..\Lib2.csproj" PrivateAssets="All" />
</ItemGroup>
This way, when the MVC.csproj is referencing Lib1, it won't be able to see any Lib2 class because you hid it in your Lib1.csproj.