A working web service is broken after installing ServiceStack.Logging.Log4Net with package-manager (in VS Express 2012 Web)
The exception thrown on initializing is:
Method 'Add' in type 'ServiceStack.ServiceHost.ServiceRoutes' from assembly 'ServiceStack, Version=3.9.4.0, Culture=neutral, PublicKeyToken=null' does not have an implementation.
This happened after installing logging in two different applications. (I deliberately tried breaking the second one by installing logging, just to be sure, and it did break...)
Cleaning and rebuilding the whole thing makes doesn't fix this.
Any help is welcome.
We've just re-deployed all the latest (v1.04) logging libraries for ServiceStack.Logging which now should be in-sync with the latest version of ServiceStack.Common libraries.
Related
Im running an Azure Function .NET Standard 2.0 and get following error:
An exception of type 'System.IO.FileLoadException' occurred in Function.dll but was not handled in user code
Could not load file or assembly 'Microsoft.WindowsAzure.Storage, Version=9.2.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
The assembly file exist in the bin/debug folder. Been reading some threads about this but without a solution (https://github.com/Azure/azure-functions-core-tools/issues/322#issuecomment-352233979), anyone know what to do?
I'm using code from another .NET Standard 2.0 project but all my projects have a reference to Microsoft.WindowsAzure.Storage 9.2.0.0 and that nuget package installed.
Thanks!
You can add reference below to downgrade your storage reference explicitly.
<PackageReference Include="WindowsAzure.Storage" Version="8.6.0" />
See this issue comment.
This restriction (like many of the other assembly version restrictions we had with other extensions) is a temporary issue and will be addressed in upcoming preview releases.
This issue has been fixed in latest host 2.0.11888, but built cli(tools to run functions) is not available yet.
Update
2.0.11888 has been available to VS users.
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
I have built a NuGet package for my Simple.OData.Client with support for Xamarin Android and iOS. This library uses Microsoft.Bcl.Async. Tests using Android and iOS simulator went OK, but when I install this new NuGet package into another project, it fails to compile Droid/Touch projects with the following message:
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(720,2): error : Exception while loading assemblies: System.IO.FileNotFoundException: Could not load assembly 'Microsoft.Threading.Tasks.Extensions, Version=1.0.12.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'. Perhaps it doesn't exist in the Mono for Android profile?
C:\Program Files (x86)\MSBuild\Xamarin\Android\Xamarin.Android.Common.targets(720,2): error : File name: 'Microsoft.Threading.Tasks.Extensions.dll'
Of course there is no Microsoft.Bcl.Async pack (yet) for Mono platforms, on the other hand since the library tests pass on these platforms, I guess this more of a challenge to make Visual Studio happy rather than do some code modification.
Has anyone managed to use on Mono PCLs dependent on Microsoft.Bcl.Async?
Generally, if the code in your package depends on another NuGet package, you need to declare a package dependency so that anyone installing your package will get the one you depend on too. That should take care of issues like this.
However, in this case it is a lot more complicated. Since Microsoft.Bcl.Async doesn't support Mono platforms, you can't declare that package dependency (or if you did it would always fail to install). Unfortunately the license for Microsoft.Bcl.Async restricts it to "Windows platforms". I'm not a lawyer but I think that means you shouldn't distribute Microsoft.Threading.Tasks.Extensions.dll as part of your package. Finally, there's no official PCL support for Mono platforms yet, so if you do come up with a solution that works now it may change when official PCL support comes out.
If you want to attempt getting this to work, what you basically need to do is create your own DLLs with the same names as are in Microsoft.Bcl and Microsoft.Bcl.Async for use on Mono platforms. In those assemblies, put type forwards for the types that Mono already implements (which should probably be the types in the System.* DLLs), and create an implementation of your own for the other ones (the AsyncBridge source code is useful for this). This is what I did for one of my BUILD 2012 PCL demos. The code for that is here. AsyncFacades and AsyncBridge are the relevant projects.
For those stumbling into this issue when getting the Simple.oData.Client from nuget, just install the following packages from nuget:
Microsoft Bcl Async Portable
Microsoft Bcl Async
I believe I've found the problem.
Earlier I had the following line in Simple.OData.Client nuspec file:
<file src="Simple.OData.Client.Core\bin\Release\Microsoft.Threading.Tasks.Extensions.dll" target="lib\portable-net403+win8+sl5+wp8+MonoAndroid16+MonoTouch40\Microsoft.Threading.Tasks.Extensions.dll" />
This is not how it should be because Microsoft.Bcl.Async should have taken care of copying Tasks.Extensions.dll. I reported this to Microsoft and expected this to be fixed in the RTM version of Microsoft.Bcl.Async. Apparently it was not, so all NuGet packages dependent on Microsoft.Bcl.Async should still copy this file. Then it will work.
for who has the same issue I think you can downgrade
System.Threading.Tasks.Extensions 4.4.0
I wrote a program on Windows 7 with Delphi Prism. I took the executable and try to run it on Linux under mono. At which point, mono raised the following error. Is this mean RemObjects components are only meant for windows environment? If not, how do you resolve this exception?
Could not load file or assembly 'RemObjects.InternetPack, Version=2.0.47.845, Culture=neutral, PublicKeyToken=3df3cad1b7aa5098' or one of its dependencies.
Unhandled Exception: System.TypeLoadException: A type load exception has occurred.
Thanks in advance,
You need to deploy and register RemObjects InternetPack on the Linux machine. It's not part of the default runtime.
Think of it like building a Delphi Win32 app with runtime packages. When you deploy the application to other machines, you also have to deploy the runtime packages.
Deploying .NET packages is a totally different question (and not really Delphi or Prism related). You might want to search here on SO first, and if you don't find an existing answer then post a new question.
I'm deploying a webpart on sharepoint and getting some errors. The webpart consumes data from a Web Service and displays a chart using Microsoft Chart (Framework 3.5). When I try to acces it, I get the folowing error:
Could not load file or assembly 'System.ServiceModel, Version=3.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
StackTrace: at
System.Web.Services.Protocols.SoapHttpClientProtocol.ReadResponse(SoapClientMessage message, WebResponse response, Stream responseStream, Boolean asyncCall)
at
System.Web.Services.Protocols.SoapHttpClientProtocol.Invoke(String
methodName, Object[] parameters)
I tried copying System.Servicemodel.dll to the bin folder and registering it on the GAC, but the error does not change.
Any idea?
Thanks
To expand on the above answers:
It does sound like your site is running on asp.net 2.x. Being that System.ServiceModel is a 3.x component, the assembly will not load. You will need to install 3.5 on the server, or if you already have it set IIS to run the site under 3.5
I had a similar problem, but it was because my .NET framework got messed up/corrupted, so I'll post what fixed it for me. Maybe it's overkill, but it worked when nothing else would.
Get the “dotnetfx_cleanup_tool” from http://blogs.msdn.com/b/astebner/archive/2008/08/28/8904493.aspx (I think one of the download links fails, so use the other one)
Uninstall frameworks 2.0 and above (I did 3.5, 3.0, 2.0. 2.0 made me reboot).
IMPORTANT: Go to C:\WINDOWS\Microsoft.NET\Framework and delete or rename the folders for the versions of .NET you removed.
Then I installed .NET Framework 2.0 SP2 (reboot afterwards). The error was gone.
I also installed .NET Framework 3.5 SP1 (works without rebooting) and the error was still gone.
Is your website configured to use ASP.NET 2.0.5.something ?
Maybe this article can be helpfull:
Forcing ASP.NET 3.5 ON IIS
Try installing .NET Framework 3.5 on your sharepoint server.
It sounds like the Web Part itself was built against an older version of the System.ServiceModel assembly (probably a beta version). If you have access to the web part's source code, you should recompile it against the latest stable version. Otherwise you'll have to find the exact same version of System.ServiceModel and register that into your GAC.
EDIT: You could also try going into your web app's Web.config and replace your System.ServiceModel reference with this:
<Reference Include="System.ServiceModel">
<SpecificVersion>False</SpecificVersion>
</Reference>
The problem was within the Web Service, not the webpart.
The machine where the web service was deployed has framework 2.0 installed.
The exception was catched on the webpart and reported back.
Thank you all for your comments.
fire up your Visual Studio 2010 Command Prompt or browse to "C:\Windows\Microsoft.NET\Framework\ v4.0.30319". And run the following command from the command prompt:
aspnet_regiis.exe -iru
I came across this same problem with a Silverlight 4 app and solved it by switch off Debug Exception checks for
Common Language Runtime exceptions
in Debug => Exceptions
Hope that helps
Mike