I have added ServiceStack.Redis via Nuget to an assembly that I have. That package has a dependency on ServiceStack.Common which has a dependency on ServiceStack.Text
this project is referenced from my web project, but when I build the Website and load it in a browser I get the error
Could not load file or assembly 'ServiceStack.Text, Version=3.9.24.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
Sure enough, when I go to the Bin directory of my website it isn't there. Oddly enough, if I go to the Bin directory of the class library I am referencing (the one I pulled the Nuget package into) it IS there.
To recap
ClassLibrary
ServiceStack.Redis via Nuget (includes ServiceStack.Common and ServiceStack.Text)
All of these make it in the Bin dir upon build
Web Proj
Refs ClassLibrary
all dependencies are moved to Bin except ServiceStack.Text
I'm stumped. Does anyone know why?
Note: The error appears to be looking for version 3.9.24, but the version Nuget pulled is 3.9.26. If I move it to the Web/Bin manually it works though
Check the assembly reference properties in your .csproj files, perhaps they are still referencing the older version of ServiceStack.Text. Sometimes I find that NuGet will fail at some point during a package update and leave your assembly references in a bad state. For example, your packages.config file may correctly show that all ServiceStack references are at the same version number, but your .csproj file may be referencing 3.9.24 for ServiceStack.Common and 3.9.26 for ServiceStack.Text. Thus, it will copy different versions of these assemblies to your bin directory. It likely can still build successfully because you have the older copy of ServiceStack.Common cached in your NuGet packages directories.
I fix this by either manually editing the .csproj file to have the correct assembly path and version number, or by uninstalling and reinstalling the affected packages via NuGet (this would likely require reinstalling most/all of the ServiceStack packages since ServiceStack.Text is such a low level dependency.
I had this somewhat bizarre problem in several versions of Visual Studio, atm 2013. It has occurred at random.
I too have dependencies on ServiceStack.Common, which implicitly depends on ServiceStack.Text. However, I am not directly at any place referencing any class, struct or the like inside ServiceStack.Text binary.
Even having set
Copy Local = true
ServiceStack.Text.dll is not being copied to the output folder.
I have experienced this with numerous versions of ServiceStack dll's, currently v4.0.15. This could be a more general Visual Studio bug concerning dependency-chains with dead ends in not directly used libraries? Probably ServiceStack.Text is marked as a dependency in other ServiceStack dll's, but Visual Studio tries to outsmart this by seeing, the library can be excluded (I'm just speculating).
Anyway, I solved it by simply using ServiceStack.Text directly in a private method put in a random used file in my own library:
/// <summary>
/// Needed because of Visual Studio bug? Don't use this method.
/// </summary>
private JsonValue DontDoIt()
{
return new ServiceStack.Text.JsonValue();
}
I would expect the compiler to exlude an unused private method - indeed maybe it does in the IL code, but none the less this makes VS copy the dll to the output directory.
As esker says there may be some problems with Nuget when updating but there are also some problems with ServiceStack Nuget packages.
The latest package working as of today is 3.9.60. ServiceStack.Text.dll is really 3.9.60.
ServiceStack 3.9.61 and above has ServiceStack.Text.dll version 3.9.59.
The copy problem is appearing again.
Related
I've got an Azure Function app that creates a precompiled DLL (so it uses normal .cs files, not the older .csx method, pre-VS2017). Previously, it was targeting .Net Framework 4.5.2. I updated it to 4.7 so as to use some of the new C# 7 features. I updated my NuGet packages by doing "Update-Package -Reinstall" and verified that they all have the "net47" target set in my packages.config file.
Everything compiles fine. But when I call a function that uses either of 2 HttpRequestMessageExtensions methods, I get an exception. One example of the exception is this:
Method not found: 'System.Net.Http.HttpResponseMessage
System.Net.Http.HttpRequestMessageExtensions.CreateResponse(
System.Net.Http.HttpRequestMessage, System.Net.HttpStatusCode)'.
Here's an example of a tiny test function that will cause the error:
using System.Net;
using System.Net.Http;
public static HttpResponseMessage Run(HttpRequestMessage req)
{
return req.CreateResponse(HttpStatusCode.Accepted, "");
}
Upon calling this function with say Postman, I'll receive the aforementioned exception. I also get a similar method not found exception when I call GetQueryNameValuePairs() on the HttpRequestMessage.
I've tried updating my NuGet packages to the latest, no difference. I've cleaned and rebuilt and restarted a bunch of times, making sure to nuke my bin and obj directories.
I'm not sure what could be the problem. I guess I could downgrade back to .Net 4.5.2 but I'd rather not. For one, I want to use C# 7, and for two, I want to understand what the problem is rather than avoid it.
Update: interesting. The issue seems to be with System.Net.Http. If I lower it to 4.0.0 everything works fine. If I raise it to any higher version I get the issues listed above. I tried selectively lowering each of my packages, one by one, to their previous version number to find this out. I then updated all but this one to the latest version and it fixed the issue.
I also tested it on my side. The issue is related to the latest version of System.Net.Http assembly(4.3.2). If I don't install this package manually or install the earlier versions(4.3.1/4.3.0), the application could work fine.
The CreateResponse method is a extension method which is written in System.Web.Http assembly(version 5.2.3). It seem that it is not compatible with the latest version of System.Net.Http. Please could just skip the error by using the earlier version of System.Net.Http and you can also submit this issue to Microsoft using follow channel.
https://connect.microsoft.com/VisualStudio/Feedback
Interesting. For me, if I got above version 4.0.0 (including 4.1.1 or 4.3.1) I still get the same problem of not finding those extension methods.
The assembly might not be updated during you change the package version. From the bin\Debug\net47 folder, we could check the current assembly version we used.
If the modified date of assembly is 2/9/2017, the package version is 4.3.1. If the modified date of assembly is 4/19/2017, the package version is 4.3.2. If the assembly is not the latest version, it could work fine on my side.
In addition, Microsoft.Asp.Net.WebApi.Client package is installed by default when creating an Azure function. System.Net.Http is one of its dependencies. So we don't need to install the System.Net.Http package manually. When running our application, NuGet will choose a right version of System.Net.Http for our application.
I had the same issue running my Azure Function locally and eventually tracked it down to conflicting System.Net.Http assemblies. I created my Azure function from a blank ASP.NET Web App and initially pulled down the System.Net.Http NuGet package to use within the project. I also pulled down the Microsoft.AspNet.WebApi.Client for use within the project. It did not matter which version of System.Net.Http I tried my project would compile but fail when the request was made.
Eventually, I removed packages I had downloaded, cleaned the build folder and added just the Microsoft.AspNet.WebApi.Client. I noticed that this automatically referenced the System.Net.Http on my machine for my version of the .NET Framework. (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework). This compiled successfully and I was able to make requests to the function without any exceptions.
Using #Aaron-Newton's insight, I identified that my issue was due to my Azure Functions project referencing a .Net Standard 2.0 class library. I switched it to .Net Framework 4.6 and it started working again. Seems like this is a bug in the Functions tooling.
I've filed a bug with the Functions team here: https://github.com/Azure/Azure-Functions/issues/477
I had the same issue. I spent quite a while to fix this problem.
The cause is that the Azure Functions project is refering to .Net Standard Library with version higher than 1.4.
Bringing down your .Net Standard version to 1.4 or lower would fix the problem.
But this is defintely a bug with Azure Functions SDK. They should fix it.
https://github.com/Azure/azure-webjobs-sdk-script/issues/980
https://github.com/Azure/Azure-Functions/issues/477
When adding the Microsoft.Azure.Devices NuGet package (I've tried 1.0.0, 1.0.2, and 1.0.4) to an ASP.NET 5 (Web API 2) project, the reference to System.Net.Http.Formatting is marked as not resolvable with
NU1001 The dependency fx/System.Net.Http.Formatting could not be resolved
There are several NU1001 issues out there, but none whose causes seem to map to this one. The best reference is this one on Github, but the resolution details were sketchy.
The reference DLL is indeed marked as Copy Local when the package is brought into a 'legacy' assembly package, so I can see why it might not find it, but can't determine the right way to fix it.
In my actual use-case, Microsoft.Azure.Devices is being referenced by a .NET assembly package and THAT is then included as a project reference in the ASP.NET 5 project, and indeed that gives the same error as trying to directly reference the NuGet from the ASP.NET 5 project.
We're using dnx452 as the only framework referenced in the project.json file.
I tried this with version 1.0.5 and it installed successfully for me.
What is the best way to handle specific version of libraries while using MonoDevelop (precisely - use ServiceStack v3 instead of ServiceStack v4)?
Unfortunately, MonoDevelop's addin NuGet does not allow specifying package version (no Package management console support). I've tried hacking it in .csproj and package.config file but it does not work entirely well and it seems to be smelly solution.
One obvious solution is to get rid of NuGet and reference libraries locally after manually downloading them.
How would you solve this problem?
Thanks for all responses :)
Being able to add a specific version of a NuGet package with the MonoDevelop addin is on the todo list.
If you have access to Windows you could use SharpDevelop to add a specific version using its Package Management console.
Or as you have suggested, edit the packages.config file, then restore the packages. However you will need to add the required assembly references by hand. This option is not that bad if there are not that many assembly references and you are not going to be updating the NuGet package very often. Although the benefit of this approach over downloading the NuGet package, extracting it, and directly referencing the assemblies is equivalent and the same amount of work. Also doing it this way you can more easily update the references by simply dropping the new binaries into your lib folder.
Or you could change the source code of the addin. I thought about adding a simple text box where you could specify a particular version. Ideally the dialog would give you a list of available versions.
I would probably just download the ServiceStack assemblies you need and directly reference them.
Our small, distributed team uses a NuGet package in a project. That package has a bug in the current release. Unfortunately the package does not publish debug symbols and source, so I grabbed & built the latest source, removed the project via NuGet and added a (temporary) reference to the project I just built locally.
Turns out, the issue is fixed in the latest code base.
This particular project only seems to release updates on NuGet every 6 months or so.
Until that next release, our team needs to use the code version where the bug is fixed.
One option certainly is to check the source code into our source code repository and keep the project reference (rather than a NuGet reference), essentially treating it as an internal utility project.
That feels "old school" though.
Is there a better way to manage this situation, using the NuGet infrastructure?
One option is to create your own NuGet package with the updated code. Then add a new Local Package source (just create a file share and place the .nupkg file there). Move the local package source up higher in priority than the official one so NuGet will use your package before looking online.
In fact I recommend copying all NuGet packages to a local repository, especially if you use package restore. This way you are not dependent on nuget.org to be up all the time (there have been several instances of downtime).
The one drawback is that when an updated package is finally published to nuget.org, Update-Package will not pick up the new one unless you specify the package source.
Anyway this will allow you to continue to use NuGet while waiting for your updated package.
So I've been working on a game, and the sheer number of projects has become unmanageable. Enter NuGet.
I wanted to ensure my code would work on different devices, so I've been making these projects as Portable Class Libraries. I needed to use these on XBox, Windows, iOS, Android, and Silverlight. I created some custom custom SupportedFrameworks in C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.0\Profile\Profile1\SupportedFrameworks
Specifically MonoAndroid and VSMonoTouch
I successfully turned one of these PCLs into a NuGet package, but when I try to add them to another PCL of the same profile I get this error:
Could not install package 'Framework.dll 1.0.0.0'. You are trying to install this package into a project that targets '.NETPortable,Version=v4.0,Profile=Profile1', but the package does not contain any assembly references or content files that are compatible with that framework. For more information, contact the package author.
The package folder was brought down and contains a folder named: portable-win+net40+MonoAndroid16+sl40+net10+wp+Xbox40 and indeed contains the requested dll. I am able to add this dll to my project manually, so I believe this may be a bug in NuGet. I investigated this online, and found the main fix was to update NuGet, because the newest version plays nicer with PCLs. I've updated, but to no avail.
Has anyone seen this before, or am I missing something obvious? Any help would be greatly appriated =)
Thanks,
Joshua
It looks like you are using ".NETFramework" for the identifier in the XML file you put in the Profile1 SupportedFrameworks folder. This was basically a hack to get iOS projects building on Windows, but with real support for that scenario you should change that identifier to MonoTouch. Then when you create the package it should use monotouch in place of net10 for the lib/portable-x+y+z folder.
Then, as #Deepak suggests, install the nightly build of NuGet. Then you should be able to install the NuGet package into your PCL project. If you do try this, please let me know whether it worked or not. :)