I believe this is not the same question as this for a couple of reason
There was no upgrading
I tried doing the x86 and x64 build and that did not work
The current versions of for newtorn.JSON are 4.5
First time working with TeamCity. The ASPNETCOMPILIER cannot load the assembly for 'Newtonsoft.json'
I do not know how to handle this. Some key points
NewtonSoft is in the packages folder
When restoring refences this could not be resolved
You're probably using indirect multiple versions of NewtonSoft.Json. As there can be only one version in the bin folder and NewtonSoft.Json is strong named, you will get
"Could not load file or assembly" errors runtime.
Solution is then to use the version 12 of NewtonSoft.Json also in your ASP.NET project, so version 12 could be loaded. It's recommend to update NewtonSoft.Json with NuGet.
If you still get load errors then with other version number, then also add to your config (if not done by nuget):
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30AD4FE6B2A6AEED" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-12.0.0.0" newVersion="12.0.0.0"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
I've encountered this sort of issues more times than I like to admit and I've been doing this for a while now, so don't feel bad. Each time it's something small that really should not be an issue. Patience is required and is good for any developer to be reminded of.
In web projects changing the target CPU does not always change the values where it's supposed to. It's probably a bug. But what you can do is go into the project file itself and check for cases of "any cpu" and explicitly change any occurrence to x64.
If that fails make sure all your references use the the most up to date version of the framework (and target cpu if applicable) required for the newtonsoft library, although I think 4.5 is fine.
Create a blank project and see if you can install the library there and have it compile correctly, less stuff in a project will make it easier to troubleshoot.
Lastly, turn on full debugging with verbose output, you might get some more detail if you haven't already done that.
The best way I've found to resolve these issues is to isolate the problem by recreating the conditions I believe exist. When creating a new project, often I'm able to assess what's changed or missing. In the case of the target CPU, I knew it could only have been a mismatch since none of my code was present when I tested it in a fresh project.
Related
I'm trying to run an webapp that is using some Azure SDK (and storage) apis but when I try to run it, I always get this runtime error.
I have the project on a Windows 7 box with Visual Studio installed and a bunch of SDKs and it works but on this new Win10 machine I'm starting it doesn't work.
msshrtmi.dll is present on the new machine on C:\Program Files\Microsoft SDKs\Azure\.NET SDK\v2.9\bin\runtimes\base\x86 (and x64 and in runtimes\net45\base) but on the old machine it is also on
c:\windows\Microsoft.net\assembly\GAC_XX\msshrtmi and I can see on IIS that is from it's loaded.
If I manually copy msshrtmi.dll to my bin folder the project works just fine. I also know this file is required form Microsoft.WindowsAzure.ServiceRuntime.
On this new machine I'm trying to avoid installing Visual Studio and using only Jetbrains Rider to build and run the project. It can build the project fine but now it doesn't run because of this.
Does the file really need to be on my windows\microsoft.NET folder? What installer puts it there? Or should I just include msshrtmi.dll as a dependency on my project?
Any other solutions for this problem?
I tried a lot of the solutions on other answers I encountered for this similar problem with no luck.
Edit: tried on ISS express 8 and 10
There are several possible ways to solve this issue:
1.Copy the msshrtmi.dll manually to your project. For example in the \bin folder next to the WindowsAzure.Storage.dll.
2.Install the Windows Azure SDK on your server.
3.Change some configurations from app.config.
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<runtime>
<NetFx40_LegacySecurityPolicy enabled="false" />
</runtime>
For more details, you could refer to this article and this one.
I am getting that error, but i am not using that version of newtonsoft
I am using version 10.0.3.
How can I find what dll is using it? or where it's coming from?
I already tried:
binding redirect in web.config, look like that: oldVersion="0.0.0.0-10.0.0.0" newVersion="10.0.0.0"
cleaning old versions installed at C:\Users\USERNAME.nuget\packages\
Cleaned the solution and rebuilt it
I'm trying to get the oracle bindings for a wcf-custom send port working.
I get this error:
Could not load file or assembly 'Oracle.DataAccess, Version=2.111.7.0
None of the installs on the oracle site seem to have this version. Any suggestions?
That would be version 11g Release 7 (11.1.7). The 2 comes from .Net 2, I believe.
My notes on installing this for 32 bit hosts are (files downloadable from Oracle):
Get Oracle Developer Tools - ODTwithODAC1110621.zip
Take defaults and select all items. Will go to C:\app[yourusername]\product\11.1.0 by default.
Then install Patchset for ODT - p6890831_111070_Win32.zip
During the install select the previous installation folder from the earlier step (C:\app[yourusername]\product\11.1.0).
Select the existing Oracle home! It might not be obvious from the screen that it is a drop down – do not select the folder.
That should give you Oracle.Data.Access 2.111.7.0 x86 in the Global Assembly Cache.
There should be 64bit versions available as well.
timobr is right on if you're trying to connect to Oracle 11g. IF you're trying to connect to 12c, you'll need to update your machine.config bindings to redirect the request for the 11g DLLs to the 12c versions. See Sandro Periera's blog for more details; here's the relevant part to add to machine.config:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Oracle.DataAccess"
publicKeyToken="89b483f429c47342" />
<bindingRedirect oldVersion="2.111.7.0" newVersion="2.112.1.2" />
</dependentAssembly>
</assemblyBinding>
</runtime>
Note this has to be done for all applicable .NET verions (including both x86 and x64).
Also note that if you're running on a 64-bit host, you'll need the 64-bit drivers - but the admin console is a 32 bit application, and will not work properly without the 32 bit drivers. However, installing both on the same machine is a bit challenging...
I was able to get a workaround to operate but it's not ideal. I noted the 'add generated items' wizard was able to connect to oracle. The code to do this is in visual studio and is 32 bit code. So I knew the 32 bit code could connect. I created a 32 bit only host and have that much working.
I never got the 64 bit drivers to work but did not try Dan Field's redirect
I'm trying to add a controller to the Controllers folder in my Umbraco 7.2 project (I've created a new empty ASP.NET MVC 4 in VS2013) but I'm getting the error
Could not load file or assembly 'ClientDependency.Core, Version=1.7.1.2, Culture=neutral, PublicKeyToken=null` or one of its dependencies. The system cannot find the specified file.
Why is this?
Normally if you add umbraco to your project, it will also add ClientDependency as a DLL reference. You should check if you have these DLL's in your bin folder.
I am pretty sure you don't have them.
IF you have the dll's in your BIN folder, it's the wrong version. In that case you need to clarify your setup more indepth.
This is a known issue in Umbraco 7.2.0 and 7.2.1 (and probably others). It has been fixed on 7.2.2 but even when/if you update you might still experience the issue.
Let's not follow the following workaround because it will put your website at risk. Read this: http://umbraco.com/follow-us/blog-archive/2015/2/5/security-alert-update-clientdependency-immediately
The suggested workaround is to run the following command in the Package Manager Console:
Uninstall-Package ClientDependency -Force
And once the uninstall is done:
Install-Package ClientDependency -Version 1.7.1.2
Source: http://issues.umbraco.org/issue/U4-5996 and https://our.umbraco.org/forum/getting-started/installing-umbraco/38333-Error-creating-Controller-in-Umbraco-v6?p=2#comment169649
Your only 2 options are really:
Update to Umbraco >= 7.2.2: Update-package UmbracoCms
Add your controllers as classes and manually inherit from Controller or UmbracoController (or other base controller classes you want to use)
I had the same problem tonight. I changed the versions in packages.config to the following:
<package id="ClientDependency" version="1.7.1.2" targetFramework="net45" />
<package id="ClientDependency-Mvc" version="1.7.0.4" targetFramework="net45" />
Make sure the bin dir matches and you should be good to go. You might need to shutdown the project in VS and reopen it too. If you run into the same issue with EntityFramework, change to 5.0.0 and make sure the correct version is in your bin dir.
Upgrading the umbraco mvc to the latest version(v7.2.2) solves the problem.
I use Nuget Package Manager v2.8.50926.663 and Visual Studio 2013.
Hope this helps you as well.
I've got an issue where my WPF application cannot be published with ClickOnce.
The application uses Nuget packages MVVM Light 4.1.26.1, Unity 2.1.505.2, CommonServiceLocator 1.0.
The problem is that when I publish, it all build fine, but I get this error when I try and install the clickonce package:
Unable to install or run the application. The application requires that assembly Microsoft.Practices.ServiceLocation Version 1.0.0.0 be installed into the Global Assembly Cache (GAC) first.
I did some digging and saw that there were two references to that assembly in the manifest, and one of them was marked as a prerequisite which I can't get rid of:
<dependency>
<dependentAssembly dependencyType="preRequisite" allowDelayedBinding="true">
<assemblyIdentity name="Microsoft.Practices.ServiceLocation" version="1.0.0.0" publicKeyToken="59D6D24383174AC4" language="neutral" processorArchitecture="msil" />
</dependentAssembly>
</dependency>
<dependency>
<dependentAssembly dependencyType="install" allowDelayedBinding="true" codebase="Microsoft.Practices.ServiceLocation.dll" size="29760">
<assemblyIdentity name="Microsoft.Practices.ServiceLocation" version="1.0.0.0" publicKeyToken="31BF3856AD364E35" language="neutral" processorArchitecture="msil" />
<hash>
<dsig:Transforms>
<dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity" />
</dsig:Transforms>
<dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha256" />
<dsig:DigestValue>eee+a+dQmhpSY/ApLxRipXdEp8UsTaZHXHClBU0Iwyc=</dsig:DigestValue>
</hash>
</dependentAssembly>
</dependency>
I'm pretty sure the issue with the ClickOnce is down to there being two references to this assembly with the same version (but notice the different public key tokens).
I created a very simple repro as follows:
Create a new WPF application
Add Nuget package MVVM Light
Add Nuget package Unity (also adds dependant package called
CommonServiceLocator)
Build and publish the WPF application
Try and install the published MyApp.application clickOnce package....get the error detailed above
Here's a repro project:
skydrive repro project
Any ideas how I might get over this?
It's now 2019 and I ran into a similar problem, found this question as first entry, but found another (more recent) problem and solution to get MVVMLight and Microsoft.Practices.ServiceLocation work together.
Mvvmlight 5.4.1.1 doesn't work with CommonServiceLocater 2.0.4 (which is both the lastest stable build in March 2019) the way mvvmlight bootstraps it's ViewModelLocator.cs
Two things worked:
either downgrading to
CommonServiceLocater 1.3.0
Mvvmlight 5.3.0.0
or changing the reference from
using Microsoft.Practices.ServiceLocation;
to
using CommonServiceLocator;
Please try again. I just pushed a new build (4.1.27.0) to Nuget that is depending on the official CommonServiceLocator package where available. This should fix your issue. If you have more problems, please make sure to let me know.
Cheers
Laurent
Yes. The MVVMLight ServiceLocation assembly uses a different public key token than every other public implementation. It has made my life a nightmare for quite some time. I finally had to rip out all my nuget assemblies and go back to file references in a common directory for now. I am waiting for Laurent to fix this.
I had this problem as well despite having the 4.1.27 build of the MVVMLight nuget package installed. After hours of frustration I figured out it was because I had the MVVMLight toolkit (v.4.1 for Visual Studio 2012) installed. Once I uninstalled it, my deployment started working again.
Just thought I'd leave this here in case anyone else runs into that particular scenario.