you would think this would be easy since Azure Appfabric is supposedly part of Azure.
Firstly Microsoft.ServiceBus.dll isnt on the VM; fixed that
Now the tcprelay bind fail: the binding type is unknown. So I called
RelayConfigurationInstaller.AddRelayConfiguration(config);
In Application_Start
Nope, same error. So I copied relayconfigurationinstaller.exe to the VM, ran it using RDP.
Nope, same error.
Any ideas?
EDIT: This is the error I am talking about
ConfigurationErrorsException: Configuration binding extension 'system.serviceModel/bindings/netTcpRelayBinding' could not be found. Verify that this binding extension is properly registered in system.serviceModel/extensions/bindingExtensions and that it is spelled correctly.]
answer: http://www.wadewegner.com/2010/05/net-framework-4-0-and-the-azure-appfabric-sdk/
the installers set the v2 clr config files; I am using v4 clr.
EDIT: well that binary works now but the API calls still dont work. (which is the preferred way of doing things)
Not pretty sure if this helps, but you need to add the AppFabric WCF extensions on your machine.config or yor app.config.
Related
I am trying to deploy a Cloud Service with 1 Web Role to Azure.
When I do so, I get this message:
Your role instances have recycled a number of times during an update or upgrade operation. This indicates that the new version of your service or the configuration settings you provided when configuring the service prevent the role instances from running. Verify your code does not throw unhandled exceptions and that your configuration settings are correct and then start another update or upgrade operation.
The project runs just fine locally, and I'm having a hard time figuring out how to start debugging this issue. Are there any common problems that cause this message or steps to figure out what is causing it?
See https://learn.microsoft.com/en-us/archive/blogs/kwill/windows-azure-paas-compute-diagnostics-data. This will walk through all of the diagnostic data available as well as how to troubleshoot the most common issues.
We also had this annoying problem and in our case:
We use local storage, but it wasn't defined in service definition (or Worker Role's properties)
Our worker role project has reference to a service project which has reference to data layer project. But, the worker role project doesn't have reference to the data layer project. As soon as we added reference to data layer project in worker role project, it deploys successfully.
Problem #1 can be easily noticed if you first run the project in your local machine. Exception will be thrown.
Problem #2, however, is more difficult, mainly because it runs just fine in local machine. After 5 days of trouble shooting, we finally found the problem. So, check all references and try to add sub-reference projects, those that are referenced by other references.
We had similar problem, and it was due to some DDLs failed to load. (due to different version from the one MS have deployed to the VM)
Try to set CopyLocal to "true" for all the References in the project, and re-deploy.
I would either remote desktop to the cloud instance and review the Windows Event Logs for exceptions or redeploy with IntelliTrace Enabled. If you choose the later, you can download the IntelliTrace logs from Visual Studio and debug
http://msdn.microsoft.com/en-us/library/windowsazure/ff683671.aspx
One way to find out the actual error is to click on the " 1 instance" at the top of Dashboard after trying to deploy your web role. It will tell you the status of the role instance. The status should include more information about the type of error which blocks your deployment.
It depends on what your case is. For me, the status claimed that I had an unhandled Security exception. After some investigation, it turned out that under my role's OnStart(), I tried to create a event source. However, Azure service doesn't have the permission to create an event source.
For more possible issues, check http://blogs.msdn.com/b/kwill/archive/2013/09/06/troubleshooting-scenario-3-role-stuck-in-busy.aspx
For me, the issue was with my SQL Azure DB firewall rules. My Azure SQL Database servers are not set to "Allow Access to Azure services", so I have to explicitly list IPs that are allowed.
I discovered this after wrapping my code in a try/catch that swallowed all exceptions, refactoring my OnStart() and RunAsync() methods, and setting all my references to Copy Local = True. None of that worked, then I saw that I had this line in my RunAsync() method:
log4net.Config.XmlConfigurator.Configure();
I am using the AdoNetAdapter for log4net and connecting to an Azure SQL DB for logging, so that led me to check the firewall rules.
For me, I had some differing version of nuget packages in my various projects. Once I consolidated everything to the same version(s), it worked fine.
With the release of Windows Azure SDK version 2.2 for Visual Studio 2012 and 2013, Now you can Remote Debug Cloud Resources within Visual Studio.
Once your cloud service is published and running live in the cloud, you can simply set a breakpoint in your local source code. This may help you in digging out what's going wrong!
I've got an existing Umbraco install on Azure cloud services (not Azure web sites), and although the web.config tells me that it should be found at ~/App_Data/umbraco.config, it isn't there.
Does anyone know where this would be stored? Is there a chance it is writing to a db table perhaps?
I need to edit some nodes as I suspect that at least one is owned by a user which no longer exists, hence no nodes at that level are visible in the admin system (JS error).
The site was set up with Umbraco Azure Accelerator, if that offers any clues.
Thanks!
It is worth noting that Umbraco hasn't needed the Umbraco Accelerator for Azure in the latest versions due to the use of Azure Web Sites. I am wondering which version of Umbraco you are running? The Accelerator projects are being deprecated and have ceased updates, as you can see here by the lack of recent updates. You can read more about the reasoning behind this, and about how the Accelerator's functionality is now a part of the Azure core itself, over here.
So - assuming that your site is an old one and you cannot just reinstall it as an Azure Web Site, can you firstly please confirm that you have the config enabled through the following setting in /config/umbracoSettings.config?
<XmlCacheEnabled>True</XmlCacheEnabled>
If this is false (as is best during all hosting environments except live) then we know that Umbraco will not use the cache. Can you please also check that the following section doesn't list any other machine IP addresses in umbracoSettings.config? Note that this is only relevant if the enabled attribute is true as in the example below.
<distributedCall enabled="true">
<user>0</user>
<servers>
...
</servers>
</distributedCall>
Next, we need to check that Umbraco is still set to use the location /App_Data/umbraco.config through the web.config file.
<appSettings>
<add key="umbracoContentXML" value="~/App_Data/umbraco.config" />
</appSettings>
We should consider the way that Umbraco works on Azure and whether it could have any effect on your site. The Umbraco Accelerator used to be necessary to synchronise the umbraco.config file between Azure instances. With each instance running a separate Umbraco website, there has to be a way that they can talk to each other. The accelerator mirrors that cache file between instances.
Assuming that your code is a default install, and not having been worked on by someone else before you, then it could be an idea to reduce your site to a single instance. Now see if it generates the cache after restarting the website. Finally, you can upgrade the site to see if it regenerates the cache.
These issues are usually always caused by some kind of configuration issue. I also remember that you can simulate Azure deployment using the Windows Azure SDK which you can use to examine for signs of the cache. Good luck.
I'm not sure about the Umbraco Accelerator or a non Web Site project, but we currently are running Umbraco on an Azure web site and App_Data\umbraco.config comes and goes when it pleases and the website unexplainably works. I would like to find the reason behind this if anyone has an answer??
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH
I am using a custom Api Token implementation using WCF Web API on Azure. This uses FormsAuthentication.Decrypt in order to obtain a FormsAuthenticationTicket. To make sure that the decrpyt process works across multiple instances, I have provided a MachineKey in my web.config.
However, I've noticed that the MachineKey doesn't seem to be working on Azure because it looks like Azure is using a random machinekey and overwriting the one I specificed in the web.config I'm using the latest Azure SDK 1.5 (or 1.6?)
I am well aware of this issue with Azure SDK 1.3 and I believe this was rectified in 1.4. Is there a chance that this issue has since re-appeared on Azure SDK1.5/1.6?
I was having the same problem where my FormsAuthentication tickets were not validating across sub domains after the recent Microsoft .Net 4.0 Security upgrade KB2656351.
My FormsAuth tickets are generated from my dedicated servers and read on sub domains on Windows Azure.
In order to get all sub domains to decrypt the tickets I made sure all my dedicated servers were patched with the latest .Net updates via Windows Update. Then I upgraded my Azure project to version 1.6 and selected the latest Azure OS after deploying. This seemed to do the trick.
Here are some articles about the issue:
http://weblogs.asp.net/scottgu/archive/2011/12/28/asp-net-security-update-shipping-thursday-dec-29th.aspx
http://technet.microsoft.com/en-us/security/bulletin/ms11-100.mspx
cheers
Francesco
Windows Azure already synchronizes machine keys across the same role in a deployment. As such, you should be fine to completely ignore the MachineKey setting in web.config and just let Windows Azure handle it for you (the web farm scenario is well supported). Your scenario is supported on Windows Azure out of box with no modifications (just call Decrypt).
The issue that you might be talking about was a 1.3 issue where the web.config files were being modified directly to sync the machine keys. This failed when the file was read-only (i.e. TFS source control) and caused deployment failures. That was fixed some time ago.
I think I finally found the solution. This had nothing to do with Azure or MachineKeys but had more to do with the way the app was being tested. The encrypted key that was stored on my Phone App was encrypted on a different web server (however, the machine key used was the same). I just un-installed and re-installed my app thereby forcing the server to generate a new key.
It seems that decrypting this key on a different server was causing problems. I'm a little worried if this will cause problems in the future. Shouldn't using the same Machine Keys ensure that encrypt/decrypt works across boxes?
Anyways, I apologize for the inconvenience caused.
We seem to have the same problem as well. We set machinekey set in the web.config file. Things were fine until a couple of days ago when Decrypt started returning null. The decryptionkey and validationkey are identical on all machines. Not sure what the problem is.
EDIT - Azure v1.6 does seem to respect the machinekey we set in the config file. We figured out how to solve our problem - Maybe this would help you - we were seeing that decrypt on the cookie does not work on our Windows 7 64 bit dev machines. Then we checked pending updates and there were a couple of .NET updates related to security. We ran the updates and voila things started to work again.
OK so I had the problem as described above in a 3-server NLB group.
It looks like the Windows Automatic Updates had installed KB2656352, KB2656358 and KB2657424 on two of the three servers.
I'd put money on the fact that it's because some of the servers are running with the patch and some aren't. I guess machines that have been patched don't like decoding things encoded by a non-patched machine (and/or vice-versa).
Anyway, I've installed all three patches on the remaining machine and put it back into the NLB group. It seems to all work fine.
Apparently the management piece of IIS - the IIS WMI provider - is installable separately from the IIS runtime.
I'd like to produce an installer for an add-on to IIS, and I know how to check for the existence of the IIS runtime in the WIX project. But, the installer needs to do various management things, WMI things, and for that it needs not only IIS, but the WMI Provider for IIS. Which as I said, may or may not be present.
In a WIX project, How do I check for the existence of the IIS WMI Provider, and how do I present a reasonable dialog to the user if the IIS WMI Provider is not present?
The installer already has a few MSI Custom Actions implemented in Javascript, and I can use
var iis = GetObject("winmgmts:root\WebAdministration");
...to check for the existence of the WMI Provider. It will fail (throw) if no WMI Provider is there. I suppose I could use this to set a Property, and then check that Property in a Condition early on in the Product.wxs file.
is this going to work? any other suggestions?
I suppose the better way for this is still to browse the registry for appropriate setting. Another question is it's not always easy to find the right one. :)
For instance, my installer needs IIS6 compatibility to be enabled (for IIS 7 machines), in particular, IIS 6 WMI compatibility. This setting is located under HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\InetStp\Components, in a value called WMICompatibility. So, everything I should do is to author a RegistrySearch element to search for this value and check if it's 1.
In order to find the correct setting, I would search for the key all IIS parameters reside under (it might differ for each version of IIS, I'm not certain here), enable IIS WMI provider you need and see what was changed in registry. I suspect registry monitor software can help here a lot.
Yes, testing instantiation of the object via the moniker is going to work. It's a reasonable strategy, better than spelunking around in the registry. It delivers the right result, all the time. Just catch the exception that occurs if the WMI provider is not available.