Although I have added the System.Web.Http assembly to my project X the HttpSelfHostConfiguration type can not be resolved. And I use resharper...
The odd thing is that the HttpConfiguration works.
When I run some integration tests from project Y using static classes in project X I get a runtime exception: The file or assembly System.Web.Http, Version=5.0.0.0 can not be found etc...
Why can I not resolve the HttpSelfHostConfiguration?
HttpSelfHostConfiguration is located in the assembly System.Web.Http.SelfHost.dll and the namespace System.Web.Http.SelfHost. So you might need to add a reference to this assembly, maybe by adding the Self Host Nuget package.
If you've already added this package, the error might be related to the other errors you're experiencing regarding System.Web.Http v5.0.0.0: I've also experienced some strange behavior after upgrading a Web API project to VS2013. I could only solve this by removing the Web API Nuget packages (the error message resembled yours), deleting some remainders of old versions in the packages folder and adding the required Nuget packages anew.
Solution:
You can add reference from the NuGet Package Library.
Search for Package: Microsoft.AspNet.WebApi.SelfHost
and install it.
For those who has any confusion in adding NuGet Package Reference:
In Visual Studio Solution Explorer, Right Click References > Manage NuGet Packages
Related
So I installed TinyIoC v1.3.0 using nuget in my Xamarin.Android project, its in the references, but I cannot type using TinyIoC; without a compile error. I would like to understand why this is?
PS. I know I can use the TinyIoC.cs file directly, but I thought it would be more convenient to update if I added using nuget.
I get this error:
I think the issue is related to the nuget package TinyIoC 1.3.0 itself.
The nuget package does not contain the lib folder with the related dll so that you can not use the format by using namespace.
Note: Important
The nuget package contains a folder called Content. This folder will copy its content into the main project with packages.config when you install the nuget pacakge. See this similar issue on so.
And it will make TinyloC.cs file directly in your main project and you can just modify it there.
I have created a net framework project with packages.config format.
However, since your project is xamarin andorid app, it uses PackageReference nuget manage format, and content folder does not work for it. Instead, you should use ContentFiles folder, but this nuget package does not contain it.
To make this issue more clearly, you should contact the author of the nuget package to report this problem.
I am trying to install MySql.Data and MySql.Data.Entity to my class lib.
Somehow there is no reference added to the project.
Things I've tried:
Update-Package -reinstall (does not help)
packages.config contains the correct entries
*.csproj also has the correct entries
Cleared NuGet-Cache
This is the output:
Package 'MySql.Data.6.10.6' already exists in folder
'C:\Users\MYUSERNAME\Documents\Repositories\XXXXXXX\packages'
Added package 'MySql.Data.6.10.6' to 'packages.config'
Successfully installed 'MySql.Data 6.10.6' to XXXXXXXX.Persistence
Executing nuget actions took 1,6 sec
Strange thing is that NuGet creates that \docs in my project which is part of MySql
Nuget-package not adding package reference
I agree with Matt`s comment. You project targets framework should be .NET 4.5.1 or below. Because the package MySql.Data only contain assembly reference to .NET framework 4.5.2 for .NET framework:
However, this package also have the content files, which are compatible with .net framework. So when you add this package to the project(target framework 4.5.1 or below), nuget will install this nuget package without any error, just add the content file (\docs) but not add any reference to the project.
To resolve this issue, you can change the target framework to 4.5.2 and above of this project or you should use the nuget package MySql.Data with the version 6.9.11, which contain assembly reference to .NET framework 4.0 and 4.5:
Note: If you change the target framework to the .net framework 4.5.2 and above, you may get the error "The package 'MySql.Data' tried to add a framework reference to 'System.ComponentModel' which was not found in the GAC.", please add a manually reference to missed library:
Package tried to add reference to System.Runtime which was not found in the GAC
Hope this helps.
I experienced this problem even though I had the correct Framework.
It was solved by Migrating the Nuget Format to Package References
For visual studio latest versions you have to right click on Dependencies > Manage NuGet Packages > click in the settings button with a flower-like shape, then in NuGet Package Manager option choose General, and change Default package management format from packages.config to PackageReference.
If that does not do the trick, then you will have to add the packages through the CLI tools, looking into the nuget gallery and pasting the comand directly with the desired version, like for example:
dotnet add package Microsoft.EntityFrameworkCore.Design --version 6.0.10
In my solution some projects reference the "MahApps" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.5.0.0. Some projects also reference the "Prism" NuGet package, which includes 'System.Windows.Interactivity.dll' 4.0.0.0.
The app.config has a binding redirect of "0.0.0.0-4.5.0.0" to "4.5.0.0" by the way.
A handful of projects reference both NuGet packages, and looking in their "References" lists some of them have S.W.I v4.5.0.0 while others have v4.0.0.0. (I'm guessing this randomness is down to the order in which the packages were installed to the projects).
Sometimes the solution will build and run fine, but if only make a code change in one of the projects referencing S.W.I 4.0.0.0 then I get a runtime error along the lines of "v4.5.0.0 could not be found". v4.0.0.0 is being copied to the build output folder but my binding redirect is telling it to expect 4.5.0.0.
Any thoughts on a solution? I could try uninstalling and reinstalling the packages in the projects causing the issue, to see if I can get them to reference the 4.5.0.0 in the MahApps package, but my concern is that this may not be guaranteed to work during a package restore, screwing it up for another developer (or the build server).
I ended up upgrading to Prism 6, which includes no DLLs other than its own. Thankfully it was a straightforward job.
I also had to remove the MahApps package then add it again, to get Visual Studio to add that package's System.Windows.Interactivity.dll (4.5.0.0).
I have noticed many times that developers tend to reference assemblies directly by browsing to the .dll file under the .\packages folder (installed by another project) and adding that to project references instead of installing the nuget package on that project. In that case, even though it compiles, but the Nuget Package Manager does not know that the referenced assembly is from a package, and so updating the package solution-wide does not update those references in that project. If you are doing a Service Oriented architecture where each piece of feature in your application is a separate project in the solution, then you probably have hundred of projects, and managing those references would become a nightmare. Is there any way to prevent developers from referencing assemblies directly if they belong to a nuget package? For example is there any MSBuild task to verify all references to package assemblies require the package to be installed on the project?
If your team uses resharper, they have a plugin to help with this:
http://blog.jetbrains.com/dotnet/2012/11/20/add-packages-not-references-a-nuget-plugin-for-resharper/
I'm guessing the issue is caused by people using resharper without it, since by default VS won't know to include that DLL but Resharper will find it and reference it (and not update package config without the plugin)
Also get used having people using nuget at the solution level, not project level. That will force people to update all nuget packages across the solution, and not leave you with V 1.1.1.0 on Project A and v 1.1.2.0 on Project B.
I'm working on a project that uses nuget but does not use package restore. (This is a decision outside of my control by the way, so any answers that involve enabling package restore aren't ones I'll be able to use.)
A handful of projects in the solution (4 out of a total of 34; a WinJS app store project, two ordinary .NET class library, and one of my Azure cloud projects) are reporting this infamous warning:
...packages\Microsoft.Bcl.Build.1.0.13\tools\Microsoft.Bcl.Build.targets(225,5): warning : All projects referencing Valhalla.Consumer.Core.csproj must install nuget package Microsoft.Bcl.Build. For more information, see http://go.microsoft.com/fwlink/?LinkID=317569.
That link assumes that I'll want to turn package restore on. So does every other bit of advice I've managed to find so far on this subject.
I tried disabling Package Restore in Options -> Package Manager -> General settings, by the way. That doesn't help (and even if it did, it would be undesirable - I use package restore in everything else I work on).
I don't really understand why I'm getting this in a solution that doesn't use package restore. As I understand it, the whole point of the package it's asking for is to support package restore. So in a solution in which package restore is not in use, it seems odd for this package to be present.
However, it appears that certain other nuget packages cause you to depend on this. I have a Windows Runtime Component project that uses Microsoft.Bcl, a nuget package that, for some reason, has a dependency on Microsoft.Bcl.Build. (Visual Studio seemed to add the Microsoft.Bcl package for me when I created the project. Presumably it's necessary.) Other projects seem to acquire a dependency on Microsoft.Bcl.Build via the HTTP client libraries.
So apparently, certain common nuget packages appear to force a dependency on Microsoft.Bcl.Build whether or not you're using package restore.
That would be fine if you could eliminate the warning simply by adding the relevant package to all projects that get this warning. But the vexing thing is that even if I add the Microsoft.Bcl.Build package to the consuming components (e.g., my WinJS Window Store app) I still get this warning! (So it continues to complain that I need to install the nuget package even after I have installed it.)
Does anyone know how to eliminate this warning in this situation? Doing what it asks me to do doesn't seem to be sufficient. What's missing?
I had the same issue. Updating the Microsoft.Bcl.Build package from 1.0.13 to 1.0.14 solved my problem.
We recently had the same issue. Using Nuget 2.8, BCL build 1.0.14, BCL 1.1.9, we had a project A using BCL build, that was referenced by another project B.
Short story: Project B compilation gave the mentioned error although the packaged were added to it. The solution was to remove the packages and re-add them. We ended up doing that for both project A and B.
I believe the cause of the problem was a mismatch in versions. The original project referenced BCL 1.1.8 (the latest version when it was created) was while project B automatically used the more recent BCL 1.1.9.
I am not sure if that's relevant but on the first time we added packages using the project->NuGet package manager, and on the 2'nd time we used the NuGet Console (Tools->Nuget->console).
The remove,add caused a distinct difference in the csproj of project B.
the following lines were added:
<Import Project="..\..\..\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.targets" Condition="Exists('..\..\..\packages\Microsoft.Bcl.Build.1.0.14\tools\Microsoft.Bcl.Build.targets')" />