My contnuous webjob stops after some time. I understand that potential reason for this could be because the WebJob SDK used to create webjob may not be supported by webapp. See details here
I am using Microsoft.Azure.WebJobs (Version: 1.1.0-beta1(Prerelease) nuget package to create my webjob.
Is this SDK supported in WebApp?My WebApp is deployed in a ResourceGroup.
Yes, the WebJobs SDK is fully supported in the Web Apps - that's the primary hosting scenario for the SDK.
As David mentioned in the other post, there are times when it is expected that your job will restart (site setting changes, file changes, etc.) If the restarts you're seeing aren't expected due to any of those reasons, then you'll want to check error logs to see what errors in your application might be causing this.
Related
Anyone has experience with FineUI UI component? I downloaded the Mvc trial package and deployed their included EmptyProject to windows Azure as an App Service, but got the following error:
The page cannot be displayed because an internal server error has occurred.
The App service URL looks like
http://mytestapp.azurewebsites.net/
There is no any details to explain this error. I even tried to set customErrors to off, but Azure didn't return more info regarding the error.
The error from Azure are resulting from below two configurations
Managed Pipeline Mode
FineUIMvc.EmptyProject is using Classic mode, we need change to Integrated as Azure App Settings is using Integrated mode by default.
targetFramework version
FineUIMvc.EmptyProject is using 4.5 by default, so you need change its version to 4.7 in Web.config to match Azure App settings. Azure provides 3.5 and 4.7 but not 4.5.
We provide the following steps to fix this:
On Azure, (SETTINGS -> Application settings -> General settings), update .NET Framework version to 4.7, and set Managed Pipeline Mode to Integrated if not. (see Azure App Settings.png file)
In project Web.config, comment out system.web httpModules and httpHandlers, instead add for modules and handlers (see http://mvc.fineui.us/#/Config/ModifyWebConfig)
Update targetFramework to 4.7
Change project Managed Pipeline Mode to Integrated
Republish the project updates to Azure and try again
We also created a testing service https://fineuitest.azurewebsites.net/ for your reference.
Of course, you can also keep Classic mode, but change targetFramework to 4.7 in Web.confg and change App Settings to Classic mode.
Hope above explanation helps.
I have an Azure MVC project, and when I try to debug it, it hangs at "Starting the role for the application in the Microsoft Azure compute emulator..."
After a while, if I try to hit the debug button again, it gives the error "The debugger cannot continue running the process. Unable to start debugging."
Any idea what the problem could be? The Azure storage emulator is running when this happens.
There are various things that can cause this and they are not all easy to find! It can be caused by a mismatch between the version of Azure tools referenced in the project and that installed on your PC.
I have had to remove everything related to Azure once and reinstall from scratch!
Another potential problem is if your WebRole.OnStart method keeps erroring, in which case, Azure will attempt to continually restart it and that can carry on for a long time. If this happens, it should eventually tell you that the roles are taking too long to start.
There can be problems if you are trying to use IIS instead of IIS Express, I have never got full IIS to work with the Azure debugger.
Try building a simple Azure app that references a default MVC app as a way to make sure it is not caused by mistakes you have made in your code or configuration. Good luck!
Not sure if this is your exact issue or not but I found the following which fixed my problem: https://stackoverflow.com/a/35407737/1399978. Issue is due to a specific Windows security update (KB3126593). Uninstall the update an everything works as it should. Hope it helps.
I know this might not help a lot of people who have been having similar problems, but I just want to note here that my issues went away when I upgraded to Visual Studio 2015 and Azure 2.8. Thanks for all the input, everybody!
I have an MVC 4 application on .NET 4.5.I have my application deployed on Azure cloud.
Up until yesterday I would make changed to my application, then check in to TFS, then my application would automatically get deployed on azure. And everything worked just fine.
But today, after I made some changes, the deployment failed with the following error message:
"The application pool that you are trying to use has the 'managedRuntimeVersion' property set to 'v4.0'. This application requires 'v4.5'."
In the azure configuration management page I have .NET FRAMEWORK VERSION set to 4.5. Furthermore there is no option for 4.0, only 3.5 or 4.5. So this seems strange.
Any ideas what could cause the problem.
p.s. I only made small changes in my Views, I didn't add any libraries or anything like that.
It is not an error in your code/configuration. There was an error in TFS service and many people had the same issue. But now it should be fixed. You can find more information on this page:
bug tracker
I have Visutal Studio 2012, MVC 4 & Razor. I am having trouble getting a website up and running with this technology.
The Web Server is a Windows Server 2008 server. I tried deploying using the Web Deploy method but am consistently getting something like 'set ACL" error.
I tried deploying using the File System. All files got deployed, but when I try and run the website, it fails because of missing ASP.NET MVC infrastruccture files.
Two things:
•If I use Web-Deploy, how do I solve the ACL error, because I assume with this method, everything needed will get deployed.
Note that the Web Deploy 3.0 service is on the server and started.
•If I use File System, where can I find the downloads needed to deploy on the server where MVC WILL work.
◦Note that I downloaded the 4.5 Framework and was successfully installed.
You need to be a bit more precise with what you need help with.
What's the exact error.
Often times you need to give the IIS users group access to at least read from the directory where you've deployed. Did you do this already?
Do you have .NET 4.5 and MVC4 installed on the server? If not, are you expecting those DLLs to be "packaged" with your deployment? They generally are not since they are "standard" assemblies. But if you want them to be included in your deployment you can do that by selecting the references in VS and saying "copy." This is not recommended because when you install patches to .NET and MVC on the server, those updates will not carry through to your app, since it'll use the local (old) copies of your assemblies.
This may be more of an IIS issue, but not sure based on the details in your question.
Check that the application pool that the site is running under is using .net 4.0.
Just a thought I would check.
I have an ASP.NET MVC web application which integrates a C# managed library of ours that loads unmanaged plugins to do some file processing. These unmanaged plugins in-turn rely on a few 3rd party libraries to do their dirty work; some of which are causing IIS to crash.
We use the exact same library in a desktop application which is able to process the files just fine. The files also process just fine when running under the Cassini web server that comes with Visual Studio 2008 (IIS and Cassini are running off the same folder on my local box).
I've done a Crash Analysis with Debug Diagnostic (img) which I'm not able to extract any useful information from.
I used procexp a bit to see if there where any failed file or registry access attempts that might be causing an issue but came up short. I didn't see any but could have easily missed them considering the number of lines produced in that kind of logging.
I configured the application pool to use a domain account and made that account an Admin on my box thinking it might be a permission issue but no luck. Are there other access restrictions in IIS that I'm not aware of?
Suggestions? Articles? Tools? Voodoo?
EDIT: I was able to debug this down to the 3rd party library's initialization routine. Since the library works fine running under other hosts I suspected either a permissions issue or memory issue. It turned out to be a stack size limitation when running under IIS. See Stack sizes in IIS - affects ASP.NET
Sounds like you should try and enable 32-bit applications in the application pool. Interop doesn't play nicely with binaries compiled for 32-bit if you're running 64-bit.