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.
Related
I was having performance issues with table storage and upgraded to the latest library/sdk. Everything works fine locally and I can run on the emulator. However, when I try to deploy to my Azure Cloud Service I get the following error:
Details: Recovering role... Unhandled Exception: Could not load file or assembly 'Microsoft.Azure.DocumentDB.Core, Version=2.11.2.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)
The web role just recycles constantly with this error. The actual dll version is 2.11.6.0. Things I have tried:
I have logged on to the web role and checked the dll is the expected one (2.11.6.0).
bindingRedirects: all relevant projects have a binding redirect of this form:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Azure.DocumentDB.Core" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.11.6.0" newVersion="2.11.6.0" />
</dependentAssembly>
I have done a text search through all files in my project for Microsoft.Azure.DocumentDB.Core - every reference (that mentions version) references 2.11.6.0. This includes files of this form dll.config file - which I did not manually edit but which do have the correct redirect.
I tried changing the Azure role osFamily to 6 (it had been 5)
I tried deleting the packages folder and regenerating
I tried deleting all redirect statements and allowing Visual Studio to automatically generate them for me.
The publish is done via 'publish' in Visual Studio 2019 on the Cloud Service (csdef).
Could anyone suggest what else I can try to deploy this cloud service?
Eventually found a way round this. So, when run locally a file WebRoleName.dll.config is produced alongside the web.config. This file is not deployed. The content is an exact copy of the web.config file. All its settings are ignored apart from the redirects. The redirects are used, seemingly, just while the web role is being started up. So, I added the file based on my local configuration (so completely the wrong database settings, etc.) to the root of my Web Role project and set it to Content - Copy Always.
Now everything runs OK - obviously it would be better if this generated file was deployed by the Visual Studio Azure publish automatically.
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 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.
I need little help regarding sharepoint solution set up in sharepoint.
I created wspbuilder project(12 hive structure including controltemplates folder)
I have created project for user controls(like login logout etc) and when I build them the .ascx files are being added to 12\controltemplates folder(I wrote postbuild event to add .ascx as controltemplate)
There are no compilation errors. I built wsp and added it to solution store. But when I am trying to deploy it to the specific web application I can see no selection of web application in deploysolution window.
It is saying
The solution contains no Web application scoped resource, and therefore cannot be deployed to a particular Web application. It can only be deployed globally.
I think the problem is adding safecontrols to the manifest.xml. When I build the wsp no safe controls are adding to the maifest.xml. I included deploymenttarget to GAC in wspbuilder.exe.config file also.
my feature.xml is as follows
<Feature Id="DBF94C51-A4AB-4c47-BD97-74D3795C6A63"
Title="site feature"
Description="My sharePoint features"
Version="1.0.0.0"
Scope="Site"
Hidden="FALSE"
DefaultResourceFile="core"
xmlns="http://schemas.microsoft.com/sharepoint/"
ReceiverAssembly="[[4part assembly name]]"
ReceiverClass="[[Receiver class]]"
>
How I can resolve this issue. I want to deploy the wsp to specific webapplication only.
Thank you.
if you are registering safecontrols, you need to scope the feature at the web application level so it know which web.config to update. Change the scope to WebApplication and it will know which web.config to deploy to.
Also when using stsadm use the -url switch to supply the web application you need.
Shane
How are you deploying this - what are the exact STSADM commands you are issuing? Do they match the scope in your Manifest file?
http://msdn.microsoft.com/en-us/library/bb861828(office.12).aspx
ohh actually it was my mistake..sorry for the disturbance.
I didn't include the key value in the wspbuilder.exe.config file. I am taking the safe controls into other specified folder in the solution. I had to include in the config file.
Now everything is fine. Thanks for the help.
I did kind of same observation as you.
I don't think it is related to gac or bin deployment of the dll, but only if there is safecontrol included.
Here is how to do it in SP2010:
http://rasor.wordpress.com/2011/12/04/sp2010-wsp-global-or-not/
I created a code behind file for a custom master page in visual studio. I hooked everything up manually; safe control and custom cas policy. Everything works great!
I then wanted to put this into a sharepoint solution using WSPBuilder for better deployment. I created WSP solution, added my class file and changed the output directory to the bin folder. I then built the solution and deployed it, making sure to change the page directives on the master page to reflect the new assembly name.
Now when I go to view the sharepoint site I get an error stating Security Exception error stating
‘Exception Details: System.Security.SecurityException: That assembly does not allow partially trusted callers.’
This has me stumped as it works as a visual studio class file deployed to the bin directory of the website.
However when I put this into a sharepoint solution it breaks! I tried adding
‘[assembly: System.Security.AllowPartiallyTrustedCallers]’
to the AssemblyInfo.cs but this hasn’t helped.
Anyone else experinced this or have any advice?
EDIT: I should also mention that the code behind is trying to access a sharepoint list.
Don´t you still have to include the SafeControls entry in order for it to work, like:
<SafeControl Assembly="[FullAssembly Name]"
Namespace="[YourMasterPageNamespace]"
TypeName="*"
Safe="True" />
or in WSPBuilder config:
<add key="BuildSafeControls" value="True" />
Never seen this.. but I suspect not many people have created codebehinds to the master pages in SharePoint (Microsoft doesn't too!).
I don't know what you are trying to build but I'd probably implement it using a server control that is included on the master page.
AllowPartiallyTrustedCallers has always fixed it for my server controls.
What is the trust in your web.config file set to? Try Full.
Are you calling a third party assembly?
I ran into a situation recently that I was using a third party assembly and it did not have AllowPartiallyTrustedCallers in its code. When I tried to use the assebmly, it would fail.
Are you sure that the assembly has been deployed to bin and no to GAC by accident? If there are two assemblies the one in GAC takes precedence.
You might try checking that you are using the fully qualified five part name including the correct public key token and namespace for your assemblies.