Summary: I have ONE project in a solution that I can't point to WebPages 3.0 (or Helpers 3.0). The others are fine, but one just immediately resolves to the Program Files x86 2.0 assembly.
Background: I have an MVC app that I inherited. I've done a few updates to it, bringing it up to MVC-3 in the last iteration. To cut to the chase, I've found myself in an unexpected bind that's seemed to snowball through my attempted fixes.
I always strive for binary deployments, eliminating the need to install packages on the build server and the web servers. Therefore, I had MVC/ASP.Net WePage binaries in the solution tree with references to those local copies.
What I've changed: Believe it or not, I've never messed with NU GET, and decided to give it a whirl. I removed all my local binaries (2x, 3x, 100x checked to make sure) and added MVC 5 and its dependencies. This seems great because I can eliminate my home-grown binary pattern in favor of the packages that are stored under the solution tree on disk/TFS. I also figured I might as well point all projects to the latest 4.5 FW.
Problems: On compilation VS is complaining that I have v2 and v3 of the mentioned DLL, but I have no references to v2. Also, before even compiling, if I remove the reference and re-add it (pointing to the package lib content) it immediately comes in as v2.0 and the resolved folder is the x86 v2 instance.
While trying to resolve this I've removed the packages and reinstalled them several times to no avail.
I've also tried adding a binding redirect to we.config, but I suspect that's a runtime thing? I have a number of other projects in this solution, all of which are fine, pointing to 3.0!
I've used reflector to look at the references for all the assemblies in the bin folder, thinking I'd find something pointing to pages 2.0, but I don't.
Looking in the csproj file I see the version hard-coded to 2.0 in the Include. I changed it to 3.0 and when I reload the solution it's reverted to 2.0. Argh!
I've closed and reloaded the solution a hundred times. I've cleaned it 1,000 times. I've manually removed the obj/bin folders multiple times.
I just don't know how else to debug this!
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly
<Reference Include="System.Web.Helpers, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\..\packages\Microsoft.AspNet.WebPages.3.0.0\lib\net45\System.Web.Helpers.dll</HintPath>
</Reference>
I found a second Include in the csproj for WebPages and Helpers! I have no idea how they got there. Uninstalling the NUGET packages would remove the FIRST reference, but not the second. To add to the frustration the second reference specified no version or location. Adding a version and location specific reference (NUGET or manually) would be overridden immediately with the GAC version!
Related
I have a well-established project that includes three worker roles. This project has always used F#, not in the worker roles themselves, but in the functions that they call. I've recently added another worker role to the project but the architecture (C# worker roles calling F# code) remains the same. Since these changes I've been getting these messages after deployment:
Could not load file or assembly 'FSharp.Core, Version=4.3.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
This happens during Autofac dependency resolution:
Autofac.Core.DependencyResolutionException", "exceptionMessage": "An exception was thrown while invoking the constructor 'Void .ctor(Amazon.DynamoDBv2.AmazonDynamoDBConfig
I know this is a well known issue, and the solution is generally to add some binding redirects. I've added a redirect thus:
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.1.0" newVersion="4.3.1.0" />
...to every project in the solution that has an app.config, which includes all the worker roles. I've also verified that every reference to FSharp.core uses version 4.3.1.0 and has copy local set to true.
I've also tried adding FSharp.core to the C# projects in the solution via the FSharp.Core nuget package.
I'm not sure why you would need a BR here as it sounds to me like this was always working and just adding a new worker role has somehow botched things up.
Without knowing your deployment process, I would suggest firstly just performing a manual package of the Cloud Service (you can do this directly from within Visual Studio or the command line using cspack). This will give you a zip file which contains all the code that will be deployed into the worker role - make sure that this contains FSharp.Core (and the correct version).
I would also suggest doing a quick diff (if you're not already done so) with what has changed since you added the new worker role in.
Lastly - watch out with the FSharp.Core Nuget package - FSharp.Core is treated differently by Visual Studio and by default won't reference the Nuget version if there's already a version of FSharp.Core referenced in the project.
I have an MVC 5 web application that I'd prefer to save time with startup by pre-compiling on publication. However, when I choose "Precompile during publishing", I get the following Error:
Error 5082 Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=2780ccd10d57b246'
or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040).
error ASPRUNTIME 0 0 USIS
The Web.Config Does have a binding redirect for this Reference
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780CCD10D57B246" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
This builds and deploys fine if I do not have this precompile option checked, and the Web is working fine without issues. I just cannot publish with this precompile option checked.
I'd really like to have the website compile all views and etc only on publish, and never recompile in the live production site. Some Documentation I was looking at was suggesting this was the propose of these features... but I'm having no luck.
EDIT: I have had some success. I realized that I was purposely not deploying the Web.Config file such that a developer doesn't accidently harm the production environment configuration, but it appears that the precompile build was copying files to a temporary location, and without the Web.Config file being deployed, no Web.Config file was there, meaning no Dependency translations.
So, Now it looks like I'm going to have to deploy the Web.Config if I want to pre-compile (I had set its Build Action from "Content" to "None", and now I've set it back again.) This means I'm going to need to look into Web.Config Transformations, or etc.
Thanks,
Greg
The only thing precompilation does is compile the views. The fact that this happens only when precompilation is set means that there's something in one of your views that is generating this error. That's kind of irrelevant, though.
The best way I've found to correct this particular error is to uninstall and reinstall the offending Nuget package.
Just go into the Package Manager Console, make sure the project that generates the error is selected for "Default Project", and then run:
> Uninstall-Package DotNetOpenAuth.Core -Force
> Install-Package DotNetOpenAuth.Core
That should resolve the issue and allow your site to publish and run fine, with or without precompilation.
Solution:
It turns out that since I wasn't publishing the Web.config file, that the binding redirects were not being made. The solution was to change this file back to being published (Build Action from "None" to "Content"), and then the pre-compilation was succeeding.
For others with an MVC or ASP.NET web site that runs slow each time hitting a new page/view, I'd recommend giving this pre-compilation feature with publishing a try. It's just hidden under file options in the publication settings (VS 2012.) I chose to Precompile, and to make the site not-updatable to avoid the dynamic view/page compilations. See for more information: What effect does the new precompile during publishing option have on MVC4 applications? .
Also, to push the correct settings and connection strings to Live and Test I started using the Translation Templates "Web.Release.config" and "Web.Debug.config". These will swap out Web.config lines when deploying only. See http://go.microsoft.com/fwlink/?LinkId=125889 for more information.
I have a workflow project in my solution that referenced Microsoft.Activies.Extensions.dll 2.0.2.16
I used the NuGet Package Manager to upgrade to the current version 2.0.6.9
Deploying the web role that references the workflow project .dll to the cloud I get:
Could not load file or assembly 'Microsoft.Activities.Extensions, PublicKeyToken=23b0c89d0d5ad43f' or one of its dependencies. The system cannot find the file specified.
I remote desktoped to the VM and checked the F:/approot/bin to see that neither version of the assembly was deployed.
Since this a NuGet package I can find it in my <Solution root>/Packages folder. I see the new folder created by NuGet but also the old version folder that was left behind although the assembly was not inside. I deleted that folder and put an assembly redirect in my web.config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Activities.Extensions" publicKeyToken="23b0c89d0d5ad43f" />
<bindingRedirect oldVersion="2.0.2.12" newVersion="2.0.6.9" />
</dependentAssembly>
Clead, build, re-deploy via Publish.
The error persists, and digging into the approot/bin again shows that the assembly was still not deployed.
I, of course, have Copy Local set to true.
Why is it not getting deployed?
Ok, resolved from finding this article:
http://weblogs.asp.net/albertpascual/archive/2008/12/16/the-cloud-for-a-fast-deployment-of-proof-of-concepts.aspx
Turns out when a web-role references an assembly than in turn references other assemblies, those assemblies will not be deployed even if Copy Local = true.
The solution is to references those child dependencies directly in the web-role project with Copy Local to true.
Only then did they show up in my approot/bin upon deployment.
I'm trying to use Windows Azure Caching Preview.
I have one dedicated cache worker role, One webrole that use the former cache, and one worker role that continuously update cache.
I followed the instructions on the Windows Azure guide but I still get an error :
Could not load file or assembly 'Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I double triple 1000000 checked dependencies, there are correct.
I noticed there were two sets of dlls : the ones version 1.0.0.0 I want to use, and another version 101.0.0.0 I don't want.
I added BindingRedirect statement to all my .config files to map 101 versions to 1.0.0.0
I checked the \bin folder, decompiled the dlls with Jetbrains, they are correct.
I begin to lose patience. Why doesn't .NET take the DLL I specify when I put the explicit path ?
Ok I found another way :
I just renamed C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\2012-06\ref\Microsoft.ApplicationServer.Caching.Core.dll to Microsoft.ApplicationServer.Caching.Core.dll_old.
It was enought for me.
Here is a more specific description of th issue : it seems to work perfectly when taking projects individually : I have 3 worker roles and one web role.
Each time I build my project one by one, I see the correct dll in output directory, I only have a problem with Windows Azure Cloud package, it seems to ignore the BindingRedirect directive.
AppFabric isn't setup to register its own DLLs after install.
You have to manually register them.
Run this in powershell to fix everything:
Set-location "C:\Program Files\AppFabric 1.1 for Windows Server"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Program Files\AppFabric 1.1 for Windows Server\Microsoft.ApplicationServer.Caching.Core.dll")
$publish.GacInstall("C:\Program Files\AppFabric 1.1 for Windows Server\Microsoft.ApplicationServer.Caching.Client.dll")
$publish.GacInstall("C:\Program Files\AppFabric 1.1 for Windows Server\Microsoft.WindowsFabric.Common.dll")
$publish.GacInstall("C:\Program Files\AppFabric 1.1 for Windows Server\Microsoft.WindowsFabric.Data.Common.dll")
iisreset
Just a suggestion to store in relevant place.
I have encountered with the problem described in the questiuon, only difference is that it could not find Caching.Client instead of Caching.Core. I tried removing libraries in SDK ref folder, as suggested in previous answer, but it did not help.
Anyway, my solution seems to be rather particular.
What helped in my case is that I found some libraries that were not referenced, but they were found among packages in the only environment where my project worked. Here they are:
* System.Web.Providers.1.1
* System.Web.Providers.Core.1.0
They were missed in packages.config file for some reason, so they could not be renewed from nuget feed.
So you might try referencing them directly or other way to make them accessible to the project you're trying to run.
I have a strange problem when trying to get the application pools on the current machine. It seems that when IISExpress is installed, the Microsoft code wants to check IISExpress in addition to the full IIS. IISExpress uses separate applicationHost files per user. I'm not sure whether this call will require it to check all of those, or just those for the current user. Regardless, it's not finding the one it's looking for in the 'C:\Windows\system32\config\systemprofile\' directory. It should be going to %userprofile% or 'C:\Users\Administrator\' for the user that the application pool that this code is executing under is running as.
Does anyone perhaps know how this systemprofile directory might be coming from?
Exception:-
System.IO.DirectoryNotFoundException: Filename: \\?\C:\Windows\system32\config\systemprofile\Documents\IISExpress\config\applicationHost.config
Error: Cannot read configuration file
at Microsoft.Web.Administration.Interop.AppHostWritableAdminManager.GetAdminSection(String bstrSectionName, String bstrSectionPath)
at Microsoft.Web.Administration.Configuration.GetSectionInternal(ConfigurationSection section, String sectionPath, String locationPath)
at Microsoft.Web.Administration.ServerManager.get_ApplicationPoolsSection()
at Microsoft.Web.Administration.ServerManager.get_ApplicationPools()
at CustomCode.Classes.IIsApplicationPool.GetApplicationPool(String iisWebSitePath, String poolName)
I highly recommend to stop using the local reference to Microsoft.Web.Administration that gets shipped with IIS (even if it's in the GAC). This is because it has a very specific version number (i.e. 7.0.0.0) and this version might change in a future version of Windows and it will hurt.
Instead, checkout the nuget package: Microsoft.Web.Administration (https://www.nuget.org/packages/Microsoft.Web.Administration). This basically makes it so you can have a private deployment of your IIS dependencies.
If the application, in which you are using Microsoft.Web.Administration to check for app-pools, is running on IISExpress, it will always fallback to Microsoft.Web.Administration version 7.9.0.0 due to an assemblyredirect in the aspnet.config in the IIS express.
See C:\Program Files (x86)\IIS Express\config\templates\PersonalWebServer\aspnet.config
Here is the problem in the config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Web.Administration"
publicKeyToken="31bf3856ad364e35"
culture="neutral" />
<bindingRedirect oldVersion="7.0.0.0"
newVersion="7.9.0.0" />
<codeBase version="7.9.0.0"
href="FILE://%FalconBin%/Microsoft.Web.Administration.dll" />
</dependentAssembly>
Make sure you are running the application in either the full IIS or on the Visual Studio Development Server.
Alternativly you could try and remove the assembly redirect, but i have not tried this, and this might cause problems in other places. We must assume that the IIS Express team made the redirect for some reason (other than convenience) :-)
I already know the answer is old but
have you tried specifying a different version of the dll?
A picture is worth in thousand words:
How are you trying to get the application pools? Are you using MWH (Microsoft.Web.Administration) APIs?
Full IIS ships with Microsoft.Web.Administration.dll (version 7.0.0.0).
IIS Express ships with a different version of Microsoft.Web.Administration.dll (version 7.9.0.0).
It seems full IIS is trying to use IIS Express specific assembly. I am not sure how you ended up in this state, but you can un-install IIS Express and see if this problem still occurs.
Edit:
Why do you want to use Microsoft.Web.Administration (MWA) version 7.9.0.0 in your web application? It is shipped with IIS Express 7.5 to work with per user applicationhost.config file ONLY and this does not use/work with inbox/full IIS configuration file that is located at \windows\system32\inetsrv\config\appliationhost.config.
In your case, web application running under full IIS is running with system identity and therefore MWA 7.9.0.0 is trying to load config file from 'C:\Windows\system32\config\systemprofile' directory.
I've just recently ran into this issue. After reading quite a few posts, this was the closest one at giving me any idea as to what was going on. While I don't necessarily have a solution to the conflict between the two versions (7.0.0.0 and 7.9.0.0) when running within the VS IDE, after a few hours struggling with it, I did find a of quirky trick you can do to work around the IDE's auto-redirection.
In the example of:
Developing an application that's referencing Microsoft.Web.Administration.dll (7.0.0.0) from the inetsrv directory and attempting to do any of the following and trying to connect properly access the application pool definitions of the real IIS, not IIS Express, with not installed. When running the compiled code outside the IDE, it always works correctly regardless of how it's specified.
ServerManager sm = new ServerManager();
sm.OpenRemote("localhost");
sm.OpenRemote("MYPC"); // Presuming you local machine's name is MYPC
These all trigger VS to redirect the reference from the 7.0.0.0 DLL to the 7.9.0.0, which causes the retrieval of incorrect sites or COM exceptions to occurs.
The quirk I found was to always use the OpenRemote(), even though trying to open the local IIS and specify "localhost" or "MYPC" as either "LocalHost" or "MyPc" (i.e. any combination of mixed case so that it is not an exact case-sensitive match to "localhost" (all lower case) or the local machine name.
This quirk may not be specific to all VS versions. I'm currently using VS Professional 2017 (15.9.11).
As I stated, it does fix the redirect, but it definitely help while debugging.
I found mapping the "TeamConfig folder" locally to my development machine helped resolved this issue for me.