I have a standard Azure build -- one web role, one worker role. After the latest merge, it has decided that the roles are invalid. When I double click on the web role or worker role, or when I right click and choose "Properties", I get a grey screen saying "Invalid service definition or service configuration. Please see the Error List for more details". However, there is nothing at all in the Error List.
I have cross-compared the Settings elements and tried commenting out sections of the csdef and cscfg files, but nothing seems to bring the roles back to life. I have wasted half a day on this already. My question is not so much "What is wrong" -- more like, how on Earth are you supposed to find out what the error is when no information is given and successive blanking out of code draws a comprehensive blank?
I've run across this a couple of times (VS 2015 Enterprise). Simply closing and re-opening the solution resolved the issue.
In this case, nothing was wrong with the csdef and cscfg files. It was the way the wadcfgx files were linked to the roles.
I'm on a branch that is using Azure 2.5; the other branch is on a previous version of Azure, that uses the older version of diagnostics. By deleting the existing wadcfgx files and re-generating them, I was able to make the roles visible and editable again. Having different versions on different branches does, of course, open a very large can of worms, but we're stuck with that difficult situation for the time being.
Check if the VM Size specified in the configuration is Small or Extra Small as it doesn't support more than that on local emulator. In my case it was defaulted to Standard Size VM. I changed the size to Extra Small and it started working fine!
I just ran into this after adding a new Worker Role project to an existing cloud service with a few existing Worker Roles.
In my ServiceConfiguration.Cloud.cscfg, I had a <NetworkConfiguration> tag in between the old roles and the new role. This was the problem. I simply moved the <NetworkConfiguration> tag to the bottom as it was before (this tag is not in my ServiceConfiguration.Local.cscfg file, which might've been the problem).
Probably not the most common cause of this problem, but figured I'd post on the off chance someone has similar settings.
Related
I am half expecting the answer to be delete everything and start over, but I figured I'd come here first after not figuring it out / finding an answer.
I created a Web App, and two deployment slots (staging / development). I created two DB's (DBName, DBName_Development). I forgot to tick off "Slot Setting" on the Development slot, and when I swapped it to Staging the configuration setting swapped as well. No problem, I figured, I will just put in the correct configuration setting and then tick off all the "Slot Setting" boxes so this doesn't occur again.
However, even after doing that, it appears my Staging site is still looking for the old DBName_Development database. Since it was changed it's not working. Not sure if I can even access the web.config for the staging site.
So, do I just trash everything and start over? Or am I missing some setting somewhere in the blades of Azure? I tried Restarting the Web App to no avail.
Thank you in advance for any suggestions/guidance/help.
You may start from Kudu console - it is the nice tooling for getting different things done with your web app.
So, if you suspect that some of your websites use something wrong or things mixed, you may go to the http://webappname1.scm.azurewebsites.net (note .scm.) and http://webappname2.scm.azurewebsites.net and compare the needed settings. If you will see that there is nothing wrong (or, vice versa, something is wrong), then you may proceed to the debug console and check the state of your web.config. And replace it if you will see that it will be needed.
I created a cloud service and tested it successfully locally. I added service configurations for stage and production. Here is a snippet of my staging-configuration:
and here my configuration-settings:
Then when I publish I set up the deployment as follows:
All this worked like 2 weeks ago. But now he deploys in VS and when I look into Azure Service Configure area it looks like this:
I played a little bit with the "Update development ..."-checkbox on the second screen but the result is the same.
So it ignores all the settings I made and just won't tranistion my configuration to the ine I named "CloudStage". My current Web PI tells me that I use Windows Azure SDK for .NET (VS 2013) 2.3. I don't get the point.
Edit
Some more things I observed:
No WADLogsTable and WADWindowsEventLogsTable is generated automatically in the staging storage.
I deactivated Remote Desktop because it was one of the changes I made to monitor the event log (which wasn't useful here)
I manually changed the connection strings in Azure Portal but it seems as if the worker is totally unaware of the storage (rebooted it with no success).
Edit
I recognized another thing. Here you can see a running deployment of my service:
See the warning-mark on the left? If I go to my Error list this is shown:
This warning is senseless since it tells me that I did everything the right way. My *.Local.csfg-files are pointing to the local storage. So?!?
This seems weird. Please check the in your ServiceConfiguration.CloudStage.cscfg to verify the expected values.
Have you tried updating any other property like Enabling Remote desktop? Does that get updated on your deployment? You should select the "Deployment Update" check box in the publish dialog. Now, when deploying to an existing Cloud Service, it should ask you if you want to replace it.
If you get the Object reference error every time you right click on project, there might be some issue with the Azure SDK set up.
I'm a little bit further now. What I did was:
Deleted all Services in Azure.
Deleted all Storage Accounts in Azure
Removed my Service-Project completely from solution (not the library containing the worker-logic).
Re-added storage-accounts in Azure.
Re-added services in Azure.
Re-added a project in the solution and added the worker-logic inside it.
Builded up all the publishing-stuff again.
Published it.
The first publish ended like the one described in my question. After I checked the "Update development..."-option in properties of my worker it finally took my transitions into the stage!
Now I recognized, that WADLogsTable was still empty. I hit the instance right in server-explorer and choosse "Update diagnostic settings...". There was an option "Transfer period" suddenly set to "None". This explained to me, why my table was empty and after I set it back to "1" my table is filling again!
Another funny thing beside: When I right-click my Cloud-project in the solution I get "Object reference not set to an instance...". When I just click it left and choose Build->Publish it works.
I just hope that I can help somebody with this. Lets see if it's stable now.
Edit: Yesterday it worked - today is still the same issue :-(.
When you get "Object reference not set to an instance.." for a CloudService project you usually have some kind of mismatch. It could be that a setting in the ServiceConfiguration is not defined in the ServiceDefinition. It could also be that there is a publish profile defined in the .ccproj file for the CloudService that doesn't exist. This might also be what is causing your problems with the different configurations.
So it turns out that the problem is completely on client-side. My Visual Studio (now with SDK 2.4) is doing something wrong. I set up a fresh installation with all the stuff needed :-( and there it works perfect. I'll try to determine if one of my extensions is causing the strange "Object reference not set..."-bug.
Repair-Installation of VS does not solve the problem btw.
I need to replace one dll-file in deployed azure worker role to one that I modified, because role contains a bug and I don't have a release tag. I'm trying to do that via rdp, but when I'm trying to copy new dll into approot folder VM tells me that old dll file is open in another program and can't be replayced.
This isn't a good idea. You should do this by repackaging the deployment and performing an update. By attempting to do this via RDP you may replace the file, but if the role goes down or gets moved then when Windows Azure bring the role back up the change will be gone since it will redeploy the last package it knew about, so you'd be back to the dll with the bug in it.
As for why it is telling you it is open is because the worker role is actively using it most likely. You'd have to stop the worker role process to be able to replace it. The best option is still to perform an update of the whole package.
You can see this documentation for more information about how the updates occur: http://msdn.microsoft.com/en-us/library/windowsazure/hh472157.aspx
I agree with MikeWo's suggestion about repackaging and updating the deployment.
However, if you want to drop the single DLL and check to see if fix works. you can kill WaWorkerHost.exe - the blue highlighted process in the picture. then you can replace the DLL.
I'm brand new to Azure. I'm trying to get a Cloud Service running with 3 web roles.
Last night I created the .cspkg and .cscfg files, exported the certificates and uploaded everything to Azure manager. The manager said my Cloud Service was successful, however for the last 10 hours when I click on "Cloud Services" in the manager it shows my service, but it says "Creating" with wait gif under "SERVICE STATUS".
Is it really still creating? Or did it fail? Is it possible to view more detailed information about the creation process and/or any log files?
Thanks,
Something "bad" has happened. Service Spin up time should be at most a few minutes.
I've seen it take up to 10-15 minutes depending on the hosting center and the number of scaled instances that need to come up but 10 hrs something has definitely gone wrong.
I would delete the service and start again. If you experience the same problem, have a look in your service start up code and make sure that there's no exceptions/infinite loops, other problems in there that might be causing problems.
It may miss any assembly references. If you included any assembly references(packages that are not part of .net) then please ensure that its copy to local attribute is set to true.
I have recently upgraded to the new Azure SDK (September 2011 v 1.5).
Ever since I have not been able to start the compute emulator. Consequently I can't debug the services on my local machine.
I have seen a suggestion that the problem lies with the fact that my user account has a space in it, so I renamed my account but that didn't make any difference. It may be that the problem is that my user profile path has a space in it. Changing the account name has no effect no the profile path.
On the msdn forums it was suggested that I remove *:808 binding in IIS Manager for Default Website. See MSDN Forums
Anyone have any other ideas?
Another option:
So, given the "rename your user account/regedit doesn't work for you, you may want to look at this MSDN article, which suggests you can just set an environment variable and run the emulator without mucking with the registry... not sure if setting the environment variable globally would let you run automatically within VS.NET without manually starting up the emulator the first time, but it is certainly easier.
Yes, the space(s) in your profile path are the issue, and this appears to be a regression for a bug that was found in a previous version of the emulator (the only reason I even thought to try logging in with a different account in the first place). I was literally just putting together a quick blog post here describing the same issue. You'll need to do some registry editing to fix all the references to your old profile path if you want to fix it, or just create a new user if you can deal with re-installing software (I love the Web Platform Installer, but I found out during this exercise that it doesn't do a good job installing for "all users").