I feel this can fall into the bucket of missing/incorrect deployed dlls but as far as I can see on the server this is the only assembly on it and its the same version that works in my local machine.
I was using IdentityModel version 3.7, specifically this constructor,
and it builds and even runs locally just fine. I deploy it to my QA Server and bam missing method exception. I even upgraded it to 3.9 and deployed just to see if that would work, no change. Unfortunately this assembly doesn't have a public key token, although I searched all drives for another version of IdentityModel.dll and didn't find any. Nothing in the GAC, restart didn't work, I'm out of ideas.
Method not found: 'Void IdentityModel.Client.TokenClient..ctor(System.String, System.String, System.Net.Http.HttpMessageHandler, IdentityModel.Client.AuthenticationStyle)'
EDIT I added some logging code
Assembly assem = Assembly.GetAssembly(typeof(TokenClient));
FileVersionInfo fvi = FileVersionInfo.GetVersionInfo(assem.Location);
string version = fvi.FileVersion;
_logger.Error(String.Format("{0} : {1}", assem.FullName, version));
and they both print off the same version on both my local box and the broken QA Environment.
Edit 2
I added logging code to log all constructors and methods and on both boxes they print off the same. I can even see my constructor logged off right before the missing method exception.
Holy cow what a trip.
So here is what the issue was, the problem assembly wasnt actually the one containing the class that threw the missing method but rather one of parameters. The System.Net.Http assembly was actually different between my local machine and QA. So really it was a missing method, there was no constructor expecting a different version of that HttpMessageHandler type. by including this in the web.config things are working for me again. The scary part is that it is actually a default parameter so you would not even notice this parameter sometimes
<dependentAssembly>
<assemblyIdentity name="System.Net.Http" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.0.0" />
</dependentAssembly>
Related
I have an asp.net core web application that uses the MSOnline PowerShell module to interact with Office 365. When the Connect-MsolService cmdlet executes to authenticate with Office 365 I'm getting the following error.
Could not load type 'System.IdentityModel.Tokens.JwtSecurityToken' from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.1.5.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
When running the same logic in another project via a unit test I do not get the error, the code executes as expected. Both the test project and the web project are using the same version (5.1.5) of the System.IdentityModel.Tokens.Jwt assembly so I don't understand why I'm getting this error when that logic executes in the web app.
I've read that a solution is to downgrade to v4 of the System.IdentityModel.Tokens.Jwt assembly but I know it works with 5.1.5 because my tests are passing. Besides, that's not an option for me because some of the aspnetcore assemblies require v5. Does anyone understand why this would happen in the asp.net core web app or know a solution that doesn't require downgrading the assembly?
Update:
It looks like my binding redirect is causing the problem. If I add the following to the app.config file in my test project it produces the error. This is very odd because 5.1.5 is the version of System.IdentityModel.Tokens.Jwt that's referenced, it's as if a different version is being used by default.
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.IdentityModel.Tokens.Jwt" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.4.0.0" newVersion="5.1.5.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
I ended up solving this by eliminating the binding redirect for System.IdentityModel.Tokens.Jwt. The binding redirect was automatically created because I was using the Auto-generate binding redirects option. I decided to just disable that option and manage the binding redirects manually to eliminate the unwanted redirect.
To make it simple I just copied the auto generated binding redirects from the output config file and pasted them into my projects app.config file. Then, I removed the System.IdentityModel.Tokens.Jwt redirect and with the Auto-generate binding redirects option disabled it only used the redirects in my app.config file instead of generating them which solved the problem.
I still don't understand why the redirect causes that error, hopefully someone will eventually shed some light on that but luckily I found a workaround.
One thing to note, if any of your dependencies use different versions of that assembly this obviously won't work. Luckily for me that isn't the case, at least for now.
I managed to get this to work by updating the assembly binding to exclude the version of System.IdentityModel.Tokens.Jwt that the Connect-MsolService was using. This worked. My updated assembly binding is:
<dependentAssembly>
<assemblyIdentity name="System.IdentityModel.Tokens.Jwt" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="5.0.0.0-5.6.0.0" newVersion="5.6.0.0" />
</dependentAssembly>
Tried to update my EF package from nuGet, but I don't think it's installing correctly.
The installer seemed to go without a hitch, but after deleting my old .Edmx model, it will not let me add a 6.x model, as that option is greyed out with the error message "Your project references an older version of EF. To use the latest version exit this wizard and upgrade before performing this action."
Research indicated that I needed to delete the System.Data.Entity reference, but that didn't fix it. The problem seems to be that my EntityFramework.dll reference is still on 5.0 (runtime version v4.0.30319), even after the upgrade. I tried uninstalling & reinstalling EF and it still puts in the old driver under references. When I remove that EntityFramework reference, I'm able to add an EF 6 model, however since the driver is old, several namespaces aren't available that I need, such as System.Data.Entity.Core. Am I doing something wrong or do I need to download a new EntityFramework.dll driver separately, and if so, where would I get that?
I've been facing similar problem few days ago. Some referenced project were using EF v4.4.0.0, but EF I added to current project (through NuGet) was v6.0.0.0. The problem is, that namespaces (and some constructors) changed between versions.
You can hack it by adding
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="EntityFramework" publicKeyToken="b77a5c561934e089" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="6.0.0.0" />
</dependentAssembly>
</assemblyBinding>
But this causes that program sometimes fails...
Method not found: 'Void System.Data.Entity.DbContext..ctor(System.Data.Objects.ObjectContext, Boolean)'.
I think that the best solution is using same version of EF across the project. Unfortunately (as in my case), sometimes you have to downgrade to old version because some projects are widely shared across the team/company.
I've been scouring the web for information on this and cannot come to a safe conclusion without finding a maching with none of the CRT dll's installed. My application is very small and I don't want to burden users with potentially bloated installs or the appearance of downloading stuff they don't need.
I'm tempted to just include the 220kb msvcm90.dll (C Runtime import library compiled as 100% pure MSIL code. All code complies with the ECMA URT spec for MSIL) and 2kb Microsoft.VC90.CRT.manifest in the application's directory. But , http://msdn.microsoft.com/en-us/library/abx4dbyh%28v=VS.90%29.aspx, states that those are now stored in the global assembly cache.
Can someone please verify my proposed solution?
A lot of what I've said is reinforced by this post, Visual C++ Redistributables without using VCRedist_x86.exe, but while he has upvotes I'm still to be convinced by the sound of independent testimony.
Please could answers make reference to my manifest which has just the one dependency:
<dependency>
<dependentAssembly>
<assemblyIdentity type='win32' name='Microsoft.VC90.CRT' version='9.0.21022.8' processorArchitecture='x86' publicKeyToken='idontknowenuff' />
</dependentAssembly>
</dependency>
As this doesn't specify just the managed runtime, it looks like my solution won't work without full installation (a 4Mb download from MS).
To further complicate things, the version of the runtime in my VC/redist directory is, 9.0.30729.1, but I assume it will be backwards compatible.
Google books turned up:
"If you compile code that uses the CRT with either the /clr option or the /clr:pure option, you'll get the appropriate pure MSIL CRT linked in instead of the native CRT", Gordon Hogenson - 2006
This seems wrong, as ILDASM shows ".module extern MSVCR90.dll" as the first line of the embedded manifest. I'll leave this answer here for GC or as a reminder that not everything that is published is gospel.
If you run in the debugger (enable mixed managed + native debugging), the modules window should show what DLLs get loaded while your program runs.
I'm trying to mole System.ServiceModel v4 in VS 2010 SP1 with Moles 0.94.51023.0 and I keep getting the following errror:
The type or namespace name 'IHttpCookieContainerManager' does not exist in the namespace 'ssm::System.ServiceModel.Channels' (are you missing an assembly reference?) [my-test-project.Test\obj\Debug\Moles\ssm\m.g.csproj] my-test-project.Test\m.g.cs 293022 43
This interface appears to have been removed from System.ServiceModel.dll in .NET 4.0 as I can only find it in System.ServiceModel.dll v2.0.5.0 (Silverlight) when I search in the Object Browser.
I'm able to reproduce this via the cmdline using moles.exe and I've tried altering the moles file to only generate type names I specify but it doesn't appear to make any difference. This was working fine prior to my upgrade to VS2010 SP1 so I suspect it's a bug, but any help would be appreciated.
Thanks
Nick
I debugged this on my own as well and found that the root cause appears to be that VS2010 SP1 (and the related GDR KB update for .NET 4) update one set of DLLs but not another:
The System.ServiceModel.dll in %ProgramFiles(x86)%\Referenced Assemblies\ doesn’t match the one in the .NET v4 install at %windir%\Microsoft.NET\Framework64\v4.0.30319...
Post VS 2010 SP1 update:
%Program Files(x86)%\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0\System.ServiceModel.dll -> File version 4.0.30319.1
%windir%\Microsoft.NET\Framework64\v4.0.30319\System.ServiceModel.dll -> File version 4.0.30319.225
Comparing these two dlls in the Object Browser in VS as well as in Reflector yields the result that the IHttpCookieContainerManager interface has been removed in the newer file. So I suspect that this is a combination of .NET probing finding the newer DLL and Moles reflecting over the older one when doing mole/stub generation. I was able to manually generate a Moles dll for the newer DLL by running the Moles exe manually with no reference paths of any kind as opposed to the MSBuild target that adds a bunch of ref paths during a build.
I don't know why that happens, but I had the same issue, and I resolved it by using Moles type filters, and only including the ones I really need (which has the nice side-effect of speeding up compilation quite a lot!!). This is an example .moles file I'm using:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name="System.ServiceModel"/>
<StubGeneration>
<Types>
<Clear/>
<Add Namespace="System.ServiceModel.Description!"/>
</Types>
</StubGeneration>
</Moles>
It looks like it was a conflict between the System and System.ServiceModel assemblies that Moles was using for compilation.
I had recently installed the Microsoft .NET Framework 4.5.
After uninstalling this and re-installing 4.0 everything worked.
Well, in case anyone is working with legacy code and happens to be cornered into using Microsoft Moles, I've done extensive digging on this topic and hope to save some from the anger and frustration I encountered.
I tried using the accepted answer's suggestion, which meant going to the Moles directory (in C:\Program Files..) and running the command line utility (moles.exe) as Administrator. There a lot of options, one of which allows you to include referenced assemblies (as suggested above).
However, even when trying to run the utility without referenced assemblies, the utility ultimately calls the C# compiler (csc.exe) with pre-defined referenced assembly paths, which is where I conclude that the confusion between .NET Framework versions occurs. I couldn't get it not to include these assembly paths.
My specific scenario was that I was trying to Mole a custom assembly, however because, apparently, I had .NET 4.5 installed on this machine, it was complaining upon compilation about System.Collections.Generics IReadOnlyCollection, IReadOnlyDictionary, and I think one other.
Solution: The only solution I got to work was to use Mole filters, which I read about on other posts and on the Microsoft Moles website (there is a special link for .NET 4.5 troubleshooting on the main page). In Visual Studio, I simply added the Moles assembly to my unit test project for my referenced custom assembly via right click in Solution Explorer. I then tried to build. For each error I received, I noted the offending classes and excluded them from being Shimmed or Stubbed by adding the following to the moles file:
<Moles xmlns="http://schemas.microsoft.com/moles/2010/">
<Assembly Name = "MyCustomAssembly" />
<StubGeneration>
<Types>
<Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
</Types>
</StubGeneration>
<MoleGeneration>
<Types>
<Remove TypeName="ClassThatUsesIReadOnlyCollectionEtc" />
</Types>
</MoleGeneration>
</Moles>
Now clearly that's not going to work if you need the classes that you're excluding from mole/stub generation, however for my case it worked fine because the offending classes were not important and I wouldn't be needing to Stub or Shim anything in those classes.
So Ive spent quite some time today with sql lite and saw the .net4 providers were very un stable. So I figured I'll use SqlCE. Its supposed to have a zero config/install instead its the most confusing way to deploy the thing.
I check numerous SO questions and these articles:
Link
Link
A More updated short guide:
http://robindotnet.wordpress.com/2010/02/28/how-to-deploy-the-sqlserver-compact-edition-software-locally/
So here is my problem, without the <runtime> tag bit, it WORKS on my DEV machine but NOT on XPSp3 without the SqlCE runtimes. It gives me a FileIOLoadException
WITH the <runtime> tag it works on XpSp3 but on my dev box it says :
Could not load file or assembly 'System.Data.SqlServerCe, Version=3.5.1.50, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I checked this answer but Im VERY confused. Also, apparently the msdn blog articles are off, you need to include 7 dlls all together. And the System.Data.SqlServerCe.dll and System.Data.SqlServerCe.Entity.dll both come from folder named "Private" where the runtimes are installed.
<system.data>
<DbProviderFactories>
<remove invariant="System.Data.SqlServerCe.3.5"></remove>
<add name="Microsoft SQL Server Compact Data Provider"
invariant="System.Data.SqlServerCe.3.5"
description=".NET Framework Data Provider for Microsoft SQL Server Compact"
type="System.Data.SqlServerCe.SqlCeProviderFactory, System.Data.SqlServerCe, Version=3.5.1.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>
</DbProviderFactories>
</system.data>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Data.SqlServerCe" publicKeyToken="89845dcd8080cc91" culture="neutral"/>
<bindingRedirect oldVersion="3.5.1.0-3.5.1.50" newVersion="3.5.1.50"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
How in the world is this zero configuration!? I have no idea what really is going wrong nor what I did to make it right? Isn't there documentation on this anywhere Other than some old blogs?
Just simply put, once I need to deploy, I just want to be able to xcopy exe and other files and it should work.So where is the reference/msdn/documentation/step-by-step on how to deploy?
Also sqlce will work on a box with ONLY .net4 installed right?
I had a very similar problem posted on S.O. in 6851346, and I just solved it.
I don't know if you are still struggling with this, but I found a solution on Code Project called Creating a Private Installation for SQL Compact that fixed my problems right up.
I hope this helps others, too.
Do you use Entity Framework? If not, the runtime tag is not required.
You must change this: Version=3.5.1.0 (in the add tag) to 3.5.1.50, and make sure you use the System.data.SqlServerCe.dll from the Private folder (it has this special assembly version)