I wrote a static method in an MVC (WebApi) website. The static method had a bug in it, so I changed the logic in the static method. The method now works on my local machine and returns the correct data.
However, Azure is STILL running the old method and returning the incorrect results. The only thing I could do was compile the library locally and FTP it up to Azure.
Why is the old static method being retained - even AFTER a build and deployment?
NOTE: I'm doing manual build/deployments from Visual Studio Online/TFS (I'm not deploying from Visual Studio). I do have Rebuild and Clean flags set on MSBUILD.
UPDATE: After looking at file sizes, apparently Azure is deploying an older version of the DLL as the DLL that's deployed is much larger than the one I'm compiling locally.
Is that new dll included in the file list you can see in preview just before you publish to your website? What are your publish options for the dll?
I assume you are using Azure Websites? Is that correct?
I'd just deploy to another Website instance, test as working using the default domain and if it all looks good redirect DNS and delete the old site.
Arggghhh!!!
After 2 days of troubleshooting, I finally figured it out.
Again, the local DLL was different than Azure's DLL in size. So I started thinking that they may be a problem w/ the file in Visual Studio Online.
So, I opened up another VM and connected to VSO to look at the source explorer. Sure enough, the file in VSO was the old version. Apparently, Visual Studio marked the file locally as being up-to-date so it wasn't being checked in with any new changes.
To fix:
Do an exclusive checkout of the file in Visual Studio
Then, attempt a check in
You should then, finally(!!!), get a merge error
Merge the local file with the file in the repository
Check the file back into VSO.
It's finally deploying correctly again.
Related
Update: this bug has been fixed for a while now
I installed Visual Studio 2017.3 yesterday and was trying to used the new Development time IIS Support feature. I think I encountered a bug, and I was wondering if anyone knows a workaround this bug. When I used it with a new project it works fine most of the time. By most of the time, is that I think it is broken sometimes depending on the where the project is located/state of cached data, etc.
Sometimes I get an error "Value cannot be null. Parameter name: name". That's the entire error. No log files, no extra information.
I tried to enable the feature for an existing project I am working
on, it got that error.
I tried adding a new web project in a new solution it worked fine. I tried adding a new web project in the same solution as my project, it didn't work.
I deleted all temp files, all bin obj and .vs folders and .user files in the
solution. Same problem.
I deleted temp folder, visual studio user profile data, and restarted the PC same problem.
I tried again in the same solution with the project not having '.' in the name, it worked.
I did some modification to the project that was working and tried to launch again I got same error.
I reverted all changes so that the project was back to the "empty project" state, still same error.
I removed the project. Exited visual studio, deleted all temp/.vs/.use/bin/obj files. Then restarted and added the project again, it worked.
I restarted VS and tried to relaunch it didn't work.
The aspnet core version seems to be not related to the bug. I had the problem with projects targeting 1.1 and 2.0 and also had the feature working for both versions.
So obviously this is a bug in VS2017.3. Since even if I am doing something wrong I should at least get an error explaining what I do wrong not an ArgumentNullException message. I already made a bug report. I am wondering if someone knows a workaround thing bug.
Thanks a lot in advance.
Update: This bug has been fixed for a while now.
After some investigation and with help from a helpful member of Microsoft's Visual Studio Team, I found that Visual Studio was failing at the point where it grants folder read access to the IIS App Pool account. The method that gets the App Pool account name was returning null, and when that null value was passed to the System.Security.Principal.NTAccount class constructor, the ArgumentNullException is thrown.
A workaround that fixed the problem for me, was changing the App Pool to any other App Pool, trying to launch, then changing it back to the original/desired App Pool.
First You Must Update Visual studio with visual studio Installer and Launch the Visual Studio installer.
And Select the Development time IIS support component and Modify.
Wait For Download is Processing
The component is listed as optional in the Summary panel for the ASP.NET and web development workload.
Then you Create New Project Again
Problem Solved.
I have a small web app developed with Asp.Net Core 1.1 deployed on Azure and it works well. I just migrated the project to use Asp.Net Core 2.0 and tried to deploy it on Azure. The deployment went fine but when I open the site, I get a 502.5 error. When I check my Azure log stream, I get the following error:
This error occurs when a CGI application does not return a valid set
of HTTP headers, or when a proxy or gateway was unable to send the
request to a parent gateway. You may need to get a network trace or
contact the proxy server administrator, if it is not a CGI problem.
Useless to say that it works well on my development machine with the same code. Note that I'm also using Entity Framework Core 2.0 although I deactivated the database creation on Azure (to check if it was not the cause).
For information, the way I migrated from 1.1 to 2.0 is by changing the target framework settings to "netcoreapp2.0" and by using the NuGet package "Microsoft.AspNetCore.All". Just to be sure, I also deleted my publish profile and recreate one.
Is it possible that Asp.Net Core 2.0 is not yet available on Azure ? I'm fairly new to Asp.Net Core, so I don't know when new releases are made available on Azure.
EDIT
When I try to run my app with dot net CLI via the debug console as proposed by natemcmaster, I got the following issue:
Unhandled Exception: System.IO.FileLoadException: Could not load file
or assembly 'Microsoft.AspNetCore.Hosting.Abstractions,
Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
The located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
I downloaded the DLL on my desktop and check the version with Dot Net Peak and indeed, the DLL is 1.1.2, although I created the project with Visual Studio and directly publish it, so is it an issue with Visual Studio ? Or Nuget ?
the issue was actually coming from the fact that, at first, my web app was using .net core 1.1, which deploys all the DLL in the "wwwroot" folder of the web application. However, with asp.net core 2.0, it does not do that anymore as the DLL are picked up from a global store. However, as Visual Studio does not clean the destination folder before a publish, I ended up with a situation where the 1.1 DLL were in my wwwroot, so the web site was picking up these ones instead of the 2.0 ones in the store folder.
This is explained in more details here: https://github.com/Azure/app-service-announcements-discussions/issues/2#issuecomment-313816550
Others have explained the reason why this is happening. I'd like to provide another – arguably easier – solution to the problem.
Just change the settings so that you remove files that are already on Azure – see below:
Check for log files either in the portal or by remotely accessing D:\home\LogFiles.
Sometimes, the logs won't indicate what is going wrong. Another good way to investigate further is to try launching your ASP.NET Core app from the Debug Console. If you are missing a shared framework version or there is another startup error, this will be more visible from the Debug Console.
Go to
https://(your web site name here).scm.azurewebsites.net/DebugConsole/
Your site will be in D:\home\site\wwwroot. You can launch it by executing:
cd D:\home\site\wwwroot
dotnet MyWebApp.dll
If you app still fails to launch, make sure that D:\home\site\wwwroot\web.config is available and configured to use ASP.NET Core Module. https://learn.microsoft.com/en-us/aspnet/core/hosting/aspnet-core-module
In my case, It was caused by having a space in the Project Name.
I can readily add a space, publish => 502.5.
Remove space, publish => good to go.
Hard to believe but I am duplicating it readily with above.
Also using "Remove Additional Files at Destination" per #Sam's Answer
See https://github.com/Azure/app-service-announcements/issues/14
"The rollout is expected to complete by Friday June 30th."
In my case the issue occurred because AppService at that time supported 2.0.0-preview2-006497 but I had 2.0.0-preview3-006890 installed which was used on build.
So I added global.json to use preview 2 SDK and it worked then
I don't know if this could help someone one day but in my case, I was using :
-Microsoft.AspNetCore.All 2.0.5
Downdrage to Microsoft.AspNetCore.All 2.0.3 resolve my problem
This happens when your version of ASP.NET Core cannot be matched on the server.
The simplest solution is to change your settings to deploy the app as self-contained, so it doesn't matter if Azure can match the framework version. Also, delete the files already on Azure, so you don't have issues when upgrading, as explained by #Sam.
Crash on Azure publish from Visual Studio. The same thing happens in previous versions of Visual Studio, but in the past I've been able to work around the bug by clearing the appdata and if necessary resorting to resetting user settings per the responses to this question about a VS2015 issue.
Azure publish has been working up to now in 2017. Suddenly I am getting the dreaded null reference, and this time clearing the aforementioned data has not helped:
Restarted Visual Studio, restarted machine, cleared data a second time including both roaming and local appdata, all to no avail.
Just for others searching, in my case the issue was that I had previously disabled the "Microsoft VisualStudio Managed Publish" extension in VS2017 (probably in an attempt to get VS to be more responsive). To re-enable it, go to Tools > Extensions and Updates, enable it, then restart VS:
Thank you for your sharing. I have the same case as you. I accidently disabled the "Microsoft VisualStudio Managed Publish" extension in VS2017. The publish menu even doesn't show up in .net core solution explorer. To re-enable it, go to Tools > Extensions and Updates, enable it, then restart VS.
Unchecking/unselecting the Application Insights in the Publish workflow of Visual Studio 2017 fix the error for me.
This can be caused by a validation error in the service definition and configuration files.
Even though the editor doesn't highlight any problems, and the build completes successfully, there can be errors in these files and they are not handled properly when you attempt to publish, giving the null reference error.
I encountered this after modifying the files per these steps to configure SSL. I really wasn't expecting that to be the culprit, but in desperation I was trying everything I could think of that might be causing the problem. As soon as I commented out the change to the <certificates> element, the null reference error went away, and the publish succeeded.
(I now need to work out why the steps for SSL configuration didn't work, perhaps due to a change introduced by VS2017, but that's another story.)
I was experiencing the same issue as the OP. I created a new DB Project and then compared the settings of the new DB Project with the DB Project that was causing the Null Reference Exception upon Build or Publish. I noticed that our output directory was redirected to a non-standard location. After deleting all the files in the bin folder, the Build and Publish started working. YMMV
I found a lot of answers around that -- so may be there are more than one -- but none worked for me.
On my system it worked again after removing the installations for ASP.NET and Azure and installing it newly .. --> evth is fine.
I'm working on an Express app that I initially created from the Basic Azure Node.js Express 4 Application template in Visual Studio. In other words, it has the web.config modifications necessary to support Express 4's www\bin structure.
This app works fine when debugging via Visual Studio or running directly via Node command line. However, deployments from source control do not work when I hooked it up to the GitHub repo. I can see the project root in the site\wwwroot folder. Even more strange, publishing directly from Visual Studio works.
This turned out to be a simple oversight, but I feel that it can easily trip up others so I'll share the answer here. I'm using the Visual Studio .gitignore file from GitHub and it includes a rule to ignore [Bb]in/ as these are usually build output. My commits were not including the contents of /bin, so my continuous deployment obviously wasn't picking these up either. Simply commenting out this line fixed this issue.
I've recently copied my visual studio 2010 website project from my windows 7 PC to a new PC running windows 8. That all went relatively smoothly. When I now publish or package the cloud project it only packages files that were originally on the windows 7 PC. Any files that I have created on the windows 8 PC are ignored. The solution builds fine and I can run and debug the project fine. Any ideas?
Not sure why that would be, but here's something to try: In Visual Studio Solution Explorer, right-click the solution and choose Clean Solution. Then try to package/publish again.
When you say files do you mean images/JavaScript?
What is the setting of the "Copy to Output Directory" ? for the files/content that is not making it...make sure it is NOT set to "Do not copy"
Are you using the new v1.8 of the SDK? (did you upgrade your project?)...this can happen if you are using an old SDK from a previous computer and then try to build stuff using a "fresh installation".
The issue was that somewhere along the way the cloud project got disassociated with the web project so wasn't actually updating the file list for publishing - it was just using the file list that had already been generated on my old PC.
The fix was to scrap the cloud project and start over with a new one, then add a new web role to it and then convert that web role into a web application project and then move my whole existing website into that...