Today, I checked my windows azure website (built with a web service) And the version was not the same as yesterday. It's very strange, it seems that ther version went backward.
So I took my project in VS and reuploaded it. Then it was good
I am quite scared, is it a normal behaviour, I think not. But how to stop this behaviour. If I remember well it's not the first time it happens to my project.
Thanks a lot for your help.
Internally if there is any problem within Azure, It is the nature of Azure to Remove the troublesome VMs and Deploy a new VM with the "cspkg" File that we upload during application deployment either through Azure portal or through Visual studio directly.
In case You make any changes through RDP to the deployed application, there is no guarantee that the application will retain the Changes.
Further more if you face this again, it is better to contact Microsoft Support, They should help you out.
Here is the explanation of the Microsoft Support :
Any changes made with Web Deploy are temporary. It can only be used for development and testing and not intended for updating applications in production. When the role instance is restarted, the changes will be gone. We would suggest that you upgrade the deployment by uploading package files from the management portal or disabling WebDeploy while deploying.
You can read more about Web Deploy here http://blogs.msdn.com/b/cloud/archive/2011/04/19/enabling-web-deploy-for-windows-azure-web-roles-with-visual-studio.aspx.
Related
I am working on bringing a working web application onto a new computer running Visual Studio 2022 version 17.4.2 and .NET Framework 4.7.2. When running on local IIS (version 10.0) host there is a "local host redirected you too many times" issue. It suggests clearing cookies which has been done with no effect.
The same code works on other machines with no issues. Is there anything in IIS set up/configuration or that may be missing from Visual Studio or other installations? Thanks in advance.
So far we have tried debugging the code and including breakpoints for where the issue may be occurring, ensuring that the installations of windows feature and IIS management is the same as another where the program is working. Also created a .txt file that can be reached on local host and is in same location as the rest of the project.
Here are a few things you can try:
Try on another machine.
Try to remove as much rules as possible from web.config and keys and so on. Or if it's a single page you're having the error with try to remove as much code from it especially if there are redirect codes. And add breakpoints and debug.
Check the LOCAL application pool version if it's set same as the online .net framework version.
I have incorporated text to speech in an asp.net webforms application which works fine when running locally. When I deploy to azure websites however it looks like a null reference is happening dealing with System.Speech.
I have tried to publish the webforms app to azure with the "Copy Local" as true on System.Speech .dll however the issue still persists.
Is there anything I am missing to get System.Speech to work on azure websites?
I have researched and found posts from a while back saying it wasn't supported but I am hoping this may of changed overtime. I will need to find some third-party TTS service if this is the case.
System.Speech is a desktop API, and definitely isn't supported on server systems. Microsoft.Speech.Synthesis is a server API and is supported on (standalone) servers. However, I'm not sure if it's possible to deploy this on Azure websites, as it requires extensive updates to the installed software (for voices, etc.).
Since azure cannot support this I found this as a valid work around.
http://translatorservice.codeplex.com/
It uses the Microsoft Translator Service.
Presently i am working on a website it has around 50 pages and links. I need to make sure that all the pages are running fine before deploying to production. Is there any tool so that i can check on local machine that no page is displaying an error message of any kind.
Note:- i am making website using ASP.Net, SQL Azure, Window Azure.
You can try this - http://www.relsoftware.com/wlv/
I'm not pretty sure what do you want to check. If it's related with your business logic you have to check by yourself, or by some unit test framework. For windows azure deployment verification, I would like to recommend you to do as below:
1, Since you said you are using Windows Azure and SQL Azure, please have two server for testing. One to simulate the windows azure environment, installed Win08 x64 (R2 if you are using Azure OS 2.x), .NET Fx 4.0 (or 3.5.1 if you are using 3.5 SP1), Windows Azure SDK, IIS with URL rewrite. Do NOT anything else on this machine, for example VS, Win SDK etc. On another machine to simulator SQL Azure, just install SQL Server 08 R2.
2, Deploy your azure application on the first machine using CSPack, CSRUN, etc. and connect to the SQL Server on the other machine, test your application. If you are using storage service, firstly using the local emulator on the first machine.
3, Change to use real azure storage and test.
4, Change to use real SQL Azure and test.
5, Deploy your application on azure staging slot and test.
6, Swap to production slot.
In SDK 1.5 and later the Azure VS Tool have a feature to help you to verify if there's any assemblies you referenced in your project are missing on azure VM. So you can set them as Copy Local = True. There's also a website help you to verify the assemblies http://gacviewer.cloudapp.net/
Not entirely sure on what errors you might want to check, but if you just only want to check for broken links then there is a tool called Xenu that could help you. It will traverse all of the links and send back nice HTML reports on the broken links.
Would ELMHA help here?
http://code.google.com/p/elmah/
Check out Wades post for Azure usage: http://www.wadewegner.com/2011/08/using-elmah-in-windows-azure-with-table-storage/
I've created an Azure server instance. I've deployed a simple application to it. As part of the deployment process I enabled Remote Desktop Connections.
I have some standard ASP.net applications that run on Windows, is there something to stop me deploying these applications manually to IIS using Remote Desktop. I've read so much about having to migrate standard ASP.net apps to Azure. I don't want to this as we will have customers who will still use Windows Server 2003/2008 so I don't want to have to maintain 2 versions.
Well, as I understand it, in theory you could deploy stuff using remote desktop. But when the instance shuts down/restarts you'll lose it all (unless you've built it into your startup scripts) and have to re-load everything each time. The main reason they suggest you have at least two instances is so that when one shuts down for updates etc there is always at least one other running.
The "Windows Azure Accelerator for Web Roles" project allows you to create an Azure web role which then enables you to use web deploy for all your other web sites - I'm guessing that will be a whole lot better approach and is definitely worth a look. Also, I believe smarx.com is a good place to browse for info and ideas.
Using a startup task and the Azure Bootstrapper you can download, unzip, install almost any kind of 3rd party software that supports either xcopy deployment (just copy the files) or an unattended(silent) install.
Assuming you aren't using Azure storage or anything like that, there shouldn't be any difference with the IIS application. If you are using anything specific to Azure, you can use the RoleEnvironment.IsAvailable to test if you are running inside Azure or not. That will return true for the emulator as well. If you want to use Azure storage from both, you can add the settings in the web.config to use if not running in Azure.
Currently our dev team set up all the websites they're working on in IIS on their local machine. We're thinking of switching to using the built in ASP.NET development server instead.
Is this a good idea? What are the pros / cons of using the ASP.NET dev Server? Are there any gotchas we should be aware of?
Thanks.
NB: Running on Win XP / IIS 5 / VS2005
Edit:
Didn't realise it was called Cassini.. More answers for Cassini v IIS here.
There is nothing that the ASP.NET Dev WebService can do that IIS can't (You can set breakpoints etc, just attach the VS debugger to the ASP.NET runtime).
However, the ASP.NET Dev WebService does not represent a true production environment, and as such you can get caught by gotchas that you wouldn't expect when you deploy to production.
Because of that, I mandate that all development is done using IIS on a local machine. It doesn't take much work to configure a site in IIS.
It's a very good idea. Here are some reasons for:
You no longer need admin access to your machine for web development (it can still be helpful).
It's much easier to test a quick change and continue work, and faster iteration cycles are good.
It can simplify setup and deployment of your development environments.
The XP version of IIS has limitation that are not present in the Server version that Cassini side-steps.
The only argument I know against is that there are a couple very rare edge cases where the Cassini built-in server doesn't exactly mimic IIS because you're using odd port numbers. I doubt you'll ever run into them, and using Cassini as the primary dev environment does not preclude developers from also having access to IIS on the machine. In fact, my preferred setup is Cassini first for most small work, then deploy to my local IIS for more in-depth testing before moving code back to the shared source repository.
[Edit]
Forgot about url re-writing. You do need IIS for that. And an example of a limitation of the built-in XP IIS is that you are limited to one site in XP (can have multiple applications, but that's a different thing).
I had to switch (back) to IIS for one project, because I needed to set some virtual directories which is not possible on the ASP.NET Development Web Server.
As I stated here: https://stackoverflow.com/questions/103785/what-are-the-disadvantages-of-using-cassini-instead-of-iis your developers need to be aware that Cassini runs as the local user, which is typically an admin account for developers. The development will be able to access any file or resource that their account can, which is quite different from what they will see on an IIS 6 server.
The other thing that's a pretty big gotcha is debugging web services is much easier using IIS and vdirs rather than separate Cassini instances.
I know at one point I had an issue with Authentication not working as expected on Cassini (built in development server)
Also, if you need to test things like ISAPI plugins (a re-writer for example) I'm not sure how that's done on Cassini.
The constantly changing port is also rather disconcerting to me. Also, for each web project in your solution it fires up another instance of a Casini server, and each one takes anywhere from 20 to 50 MB of memory.
I use IIS all the time, it's pretty easy to setup, and you guys are already doing that...
I've used both methods and I prefer having IIS locally vs. using the built-in server. At very least you're more consistent with the final deployment setup.
Also, when using IIS 5.1, be sure to get JetStat IIS Admin, it adds functionality that is disabled out of the box on IIS 5, such as being able to setup multiple sites.
I have run into the following limitations with the asp.net dev server:
does not support virtual dirs. If you need them in your app, IIS seems to be your only choice
Classic asp pages dont run in dev server. So if you have a mixed web app (like I have at my client right now), IIS seems to be the solution
If you need an admin UI to configure settings, IIS works better
Of course IIS requires that you be a local admin.
Another distinction I noticed is that Cassini runs as a 32-bit process and you have no control over it, whereas you can control the application pool of your IIS app to disallow 32-bit (assuming your IIS is running on a 64-bit server). This becomes especially important if your web application is going to call APIs in 64-bit processes such as SharePoint Foundation/Server 2010. When you debug your web app with Cassini as your debug server, you'll get "The Web application at url could not be found. Verify that you have typed the URL correctly" type errors when instantiating objects. If you debug using IIS with the app running in an app pool that runs as 64-bit with an identity that allows access to sharepoint database then you'll be able to debug properly.
In VS12 the development server is way slow, takes a few seconds to download a 2kbyte file. This did not happen in vs10. When you have a bunch of jquery files and css this is a real problem. Also every page requeries all the css/js files. Very very slow regression testing.
The main issue I've run into with the dev server is SerializationExceptions with custom security principals stored on the thread context. Details here.