I'm trying to publish a project to an Azure Web App via Visual Studio 2015. This is an MVC 4 targeting Framework 4.6.2. The publish procedure claims in VS2015 to have finished successfully, however, when the browser is launched to display the published site, it errors out with a 502 error (bad gateway/proxy) on the favicon.ico file. Obviously, that's not what's really happening.
I downloaded my eventlog.xml file from the Web App and looking at the error being reported, it's claiming that it's unable to find assembly 'EntityFramework, Version=6.0.0.0...'. However, I see the EntityFramework.dll contained within the project bin folder. But, just to see if it made any difference, I tried using Kudu to install EntityFramework from NuGet, as well as doing a nuget restore using the packages.config file that was successfully pushed up to Azure. All that did was restore a ton of files where I didn't need and the same error remains.
Has anyone else seen this issue and have any recommendations on how to resolve it? I'm not sure what else I can post to give a clearer picture of what's going one...it's not like there's any code or source, and the eventlog.xml file shows little more than the YSOD error message for a missing assembly.
Please, any assistance would be greatly appreciated!
I've had this in the past - if you read the error message carefully it says it can't load that assembly or some of its dependencies - so it may well be another dll that's missing from your application.
Use the Console blade in the portal (or the separate Kudu site and console if you prefer) to compare the bin folder contents with that on your dev/test environment and see what's missing - if you stick to using nuget packages then you shouldn't be able to go far wrong, but I think I still had problems a while ago with EF when I didn't reference the EF libraries directly from the web app, but only from a repository assembly that was referenced from the web app.
If you're not using Nuget and referencing the dependencies directly make sure the referenced dll's "copy to output" properties in VS are set correctly, such that the dll's end up being copied to your project's bin folder and included in the package that gets deployed to Azure.
Well, it turns out this one was one of those "that's not the real issue" error messages. Thanks to Russell and Karel. You input led me to verify a few things and make sure I had all things referenced properly.
Here's what I found out...our DEV SQL VM is turned off on the weekends to conserve resources (aka $$$). After sending all files from my local bin directory via FTP, I browsed to the site and received the same error. Downloading the logs, however, showed that I couldn't reach the db server using Named Pipes. Whoops...one of the connection strings (in the repository project) had not been set to the FQDN, so it wasn't using TCP/IP for the connection.
I fixed that, published the site, turned ON the sql server, and now the site is working as expected.
Moral of the story, make sure you have all connection strings set properly.
Related
I am suddenly seeing this error when running my app (published on Azure app service:
Could not load file or assembly 'Microsoft.SharePoint.Client, Version=16.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c' or one of its dependencies. The system cannot find the file specified. at SharePointLibrary.SPClient.GetAllUsers()
at ADVWKSP.Managers.UserManager.GetUsers() in C:\Users\bassie\source\repos\TFS\ADVWKSP\ADVWKSP\Managers\UserManager.cs:line 21
It runs fine on my machine, and it used to run fine after publish but now it just suddenly starts crying about this file missing.
I checked in Kudu and I can only see the SharePoint.Client.Runtime:
Why? How can I ensure that all required libraries are published with the project. Why did this suddenly stop working?
The hosting environment of azure web app contains a standard installation of .Net framework 2.0 to .Net framework 4.5.
If your application referenced assemblies which is not build in .Net framework, you have to "include" them with your deploy package.
Even these are Microsoft assemblies.
Setting the Copy Local property to True for the referenced assembly may fix it.
1.In Solution Explorer find your project's reference to the library.
2.Right click and choose Properties.
3.In the Properties window set Copy Local to True.
As you said, it works locally on IIS Express, please try to deploy your website content manually to Azure via KUDU or FTP client and find out whether it works or not.
Adding the following parameter
/deployonbuild=false
to the msbuild command line fixed the issue.
I faced the similar kind of issue when my app service function version was 3, but function source was targeted function version 4. updating the app service sorted the issue
I have a cloud service project with three worker roles. Previously (VS 2013, Azure 2.5) everything published fine. When VS 2015 was available, I installed it on a clean VM and then installed Azure 2.7. I promoted my old solution and I can build and run locally just fine. I can build the cloud service project. But when I try to publish or package, I get the following error and the build fails.
Error:
Access to the path
'C:\Users[username]\AppData\Local\Temp\3xhd2e4m.wlw\roles[rolename]\base\x86\msshrtmi.dll'
is denied. C:\Program
Files\MSBuild\Microsoft\VisualStudio\v14.0\Windows Azure
Tools\2.7\Microsoft.WindowsAzure.targets 3003
When I go to Temp - there is no directory corresponding to 3xhd2e4m.wlw.
My resolution attempts so far include:
Removing the worker roles from the solution and trying to publish - fails with same error for the remaining project.
Removed read-only from temp
Tried to set everything to build x64
I really need some help since this blocking deployment and testing.
I have the same problem. According to an answer in another post (Deploying to Azure: "Access to the path ... msshrtmi.dll is denied"), the problem is related with an issue with the Azure SDK 2.7 and will be solved in version 2.7.1, supposed to be released shortly.
The problem occurs only when you try to publish from a 32-bit machine. Changing to a 64-bit machine should work.
I can't offer a specific solution as I haven't taken the plunge and upgraded to VS2015 yet, however I imagine this has something to do with the project file for the Worker Role's Cloud Service.
So, two options come to mind:
Create a new blank Worker Role Project with a single boilerplate Worker Role and check that it publishes/packages correctly. This will confirm whether this functionality works in VS2015 with Azure SDK 2.6.
If (1) works, consider adding one of your existing Worker Role Projects to the blank Worker Role Project in (1) and try the publish/package process again.
I find it hard to believe that the chaps at Microsoft have tried the upgrade path from v2.5 -> v2.6 of the SDK for Worker Roles... I've checked the v2.6 Release Notes and there doesn't appear to be any breaking changes related to this issue: https://azure.microsoft.com/en-gb/documentation/articles/azure-sdk-dotnet-release-notes-2_6/
I just got hit with this same issue and lost a few brain cells from it.
I have a defined directory in my ServiceDefinition.csdef that contains all the files I'm trying to copy out during my cloud service publish for my startup tasks, and I ended up including some .dll files as well. I was getting the same error as the OP of this question and after some time found out that I just couldn't include the *.dll files in my SourceDirectory path. I was able to include .cmd files just fine, but .dll and .config's were no good.
It wasn't good enough to exclude them from my project either, just the fact that the files were in that directory was enough to make VS yell at me.
For now I've just put all the offending files in a zip and I'm sending the zip file in my deployment, so it's a workaround, but was a painful one until I figured this much out.
Hope this helps..
Hello,
I am facing a problem with a WPF project that I am working on. The application works perfectly when I build it on my local machine, but when built on TFS server, it fails at runtime with an exception 'Cannot find HomePage/HomePageView.xaml'. Attached is a screenshot of the difference between the dll built on build server & the one built on local machine. Build server gets rid of the 'HomePage' folder path for some reason. Any help on why this might be happening would be appreciated.
Also attached is a screenshot of my project layout.
Based on the screenshot You provided, it seems that some files in this project are in fact added as links and the real files exist somewhere else (the little arrows on files icons indicate this).
Please make sure that TFS build server can actually access those files in their original location while building the project.
You mentioned that the build works on Your local machine, but it's not clear if You have only rebuilt the application or use Publish option. If not, please verify if publishing the project locally works correctly.
I also saw some article describing issue when using linked files and MSBuild, but it was rather related with web applications. You can find some information about it here.
I had two applications that was able to run on my local machine in asp.net through visual studio. A webservice and a web forms app. I decided to try and deploy the webservice to my web host online, but it didnt work, so i tried to remove the reference i had to the MySql data connector and then move it to the "bin" folder and re-reference it. This resulted in that my local application broke, and when i tried to undo what i had done, it just remained with the same error. I have tried to uninstall and install various versions of the MySql connector, but without luck. The reference to the MySql connector also got broken in the web forms app, which i didnt delete the reference in, so now neither of them runs.
"Adgang nægtet" means "Access denied".
Here is the error for the webservice
http://pastebin.com/81wuP68j
And here is the error for the web forms app
http://pastebin.com/LVuUy9Yg
Is there any way to start from fresh? I read on a related question, that a guy suggested to reinstall windows, but that isn't a viable option at all.
EDIT: Apparently when i was re-referencing to a new MySql dll file, it was a wrong version of it, so after installing a new one (a second time), and moving it into the bin, and referencing to it, it worked.
Does the shortcut in the Start Menu set the working directory
correctly? (I suspect that this is the most likely answer)
Is there a different/incorrect version of MySql.Data.dll installed
in the GAC (Global Assembly Cache)? I've seen this give similar
error messages before.
Set 'Copy To Local' the Mysql.Data.dll reference from properties.
If MySql.Data is a mixed mode (native and managed code) 32 bit DLL.
And you executable specifies "Any CPU". On a 64 bit machine with 64
bit .NET this will fail with error message you got. A solution is to
specify "x86" as target for the executable.
I am working on a webserver that has ASP.NET 2.0 as the activate instance of ASP.NET (I can't change it. I don't have control over it.)
I orginally wrote the site in 4.0, not even thinking to ask what version the webserver was in. When it came to installing, I realized the error and changed the targeted framework. After a little bit of wrestling with VS 2010, it compiled fine.
I put it up, and now it is giving me this error:
Account used to be a .cs file, which I then put into it's own project so I could get in a DLL in hopes of it working with it being a dll. It always fails when it comes to the first thing that references Account.
Account is compiled against .NET 2.0.
Any help? D:
Edit: The other important thing that may change this, is that the person is already hosting another ASP.NET site on the main folder. He wants to host this site in a subfolder.
I have read that ASP.NET may not like that, so could that be the issue?
Check following:
Your application referencing assembly with Account class;
Corresponding assembly existing in web application 'bin' directory - you may referenced it, but not specified as 'copy always' in reference properties.
You built it, not just put into 'App_Code' (it is bad practice to put code in the App_Code for asp web application as I know)
Also, your error appeared only on 'production' host or reproduced also on VS devserver?