I’m getting the following behavior when I try to launch an Azure Cloud Service locally
1) Popup that the debugging environment is getting ready is shown (step1.jpg)
2) Message “Your about to be signed out, crypto settings changed” is shown (step2.jpg)
3) Force restart of the notebook is performed (step3.jpg)
This is happening constantly in both debug and start without debugging options.
I tried changing the properties of the azure cloud service but it didn’t help. I also tried to use the internet what does this message mean and could not find any relevant data. appreciate ANY help. Thanks!
Check you ServiceDefinition.csdef for startup tasks. I think you maybe running the DisableSslv3.cmd script on your local machine causing it to force a restart. Just comment out the line while debugging locally.
In addition to the answer of #user2282308, I would say that in a more global approach, it worth to check the startup tasks in the serviceDefinition.csdef and verify that all tasks are executed as "expected".
#user22822308 spoke about DisableSslv3.cmd, but on my side, the issue was that the script runTLSsettings.cmd should be executed only when running on Azure service (this script ends with a reboot of the machine and the famous "crypto settings changed")
This is the serviceDefinition.csdef integration that is proposed by Microsoft for the runTLSSettings script:
<Startup>
<Task executionContext="elevated" taskType="simple" commandLine="RunTLSSettings.cmd">
</Task>
</Startup>
This is ok when debugging your cloud service in Visual Studio 2019, but as soon as you try to debug with Visual Studio 2022 you will receive the "Crypto settings changed".
My feeling is that the startup task is not done in VS 2019 meanwhile it is done in VS 2022.
Thus, what is missing is the definition of the environment variable that indicate to runTLSSettings script if we are running on emulator or not.
The environment variable definition is well explained in this other microsoft documentation:
https://learn.microsoft.com/en-us/azure/cloud-services/cloud-services-startup-tasks#environment-variables
At the end, this is the correct csdef:
<Startup>
<Task commandLine="runTLSSettings.cmd" executionContext="limited" taskType="simple">
<Environment>
<Variable name="ComputeEmulatorRunning">
<RoleInstanceValue xpath="/RoleEnvironment/Deployment/#emulated" />
</Variable>
</Environment>
</Task>
This happens every single time I run Visual Studio without elevated privilege's. When I start debugging the cloud service and the azure emulator starts, I get this message and the computer reboots.
We have a client Windows application calling C# Web Services. Everything is in .Net Framework 4.0.
So basically, we deploy Web Services in IIS, and also the client application will be located on the server. The application will be executed on client PCs via a network share.
Everything works fine, every functionality works ok (Web Services, Windows functionalities, etc).
But we have an error reporting functionality that reads customs definition in the .Config file. The section looks like this:
<configuration>
<configSections>
<section name="exceptionManagement" type="Some.Namespace.ExceptionManagerSectionHandler,Some.Assembly"/>
<section name="ProductInformation" type="Some.Namespace.ProductInfoManagerHandler,Some.Assembly"></section>
</configSections>
The section will be read only when the application encounters an exception.
When executing the application locally on the server, the error reporting will work fine, but when executing the same assemblies from a network share (even on the same machine with a shortcut using the FQN of the machine and share), I will get this exception (line 5 is my "ProductInformation" custom definition):
Exception has been thrown by the target of an invocation. An error
occurred creating the configuration section handler for
ProductInformation: Request failed.
(\\Server\PATH\Some.exe.config line
5) Request failed.
But as I told before, every other functionalitiy will work just fine. And, of course, I got this at the end of my config :
loadFromRemoteSources enabled="true"
I really don't get it, since basically the code is fine when ran locally, but fails when ran from network share, but all other functionalities will work fine over network.
Any ideas?
I've created a bare-bones NServiceBus endpoint (which doesn't do anything for now), and when I install it (using NServiceBus.Host.exe /install /displayName:"MyEndpoint"), it gets installed as a service
that runs under Local Service, and it works perfectly.
Now, when I change the Run as account for this Windows Service to my own local service account (lets call it "svcTestAccount" for now, it has Logon as a service permission), the service starts and then unexpectedly stops halfway during its initialization.
I can't tell why, since no exceptions get logged to log4net, the process just terminates.
I've seen this behaviour before in a previous project when the endpoint couldn't access the queue it needed, but this time I have configured the 5 queues that my endpoint to give "Everyone" "Full Control", so it shouldn't be that, right?
What's strange is that, when I run it (using the NServiceBus.Host.exe on production profile), it happily runs in all the following situations:
From within Visual Studio 2012, running as local admin.
As a windows service, running under Local Service
As a windows service, running under Network Service
As a windows service, running under svcTestAccount, if svcTestAccount is a member of the local Administrators group.
From a command prompt running under svcTestAccount (i.e. "runas /user:svcTestAccount cmd" to open the command prompt, then NServiceBus.Host.exe to run my endpoint)
The only thing that doesn't work is getting it to run as a Windows Service under svcTestAccount (and not being a member of the local Administrators group).
Can anybody tell me what's going on?
For completeness sake, my endpoint only consists of:
public class EndpointConfig : IConfigureThisEndpoint, AsA_Publisher, IWantCustomInitialization
{
public void Init()
{
Configure.With()
.DefaultBuilder()
.Log4Net();
}
}
And my web.config:
<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<configuration>
<configSections>
<section name="UnicastBusConfig" type="NServiceBus.Config.UnicastBusConfig, NServiceBus.Core" />
</configSections>
<UnicastBusConfig>
<MessageEndpointMappings>
</MessageEndpointMappings>
</UnicastBusConfig>
</configuration>
I'm using NServiceBus 4.3.0 on Windows Server 2012.
To run NServiceBus host as a different account (not Local System) you need to execute the installer with /username and /password, eg:
NServiceBus.Host.exe /install /displayName:"MyEndpoint" /username:"mydomain\username" /password:"mysecretpassword"
See http://docs.particular.net/NServiceBus/the-nservicebus-host#installation for more info.
I have an ASP.Net application with 2 modules:
A server module, runs as a windows service.
A web module installed on IIS.
The above works perfectly (have been working) for last several years. Problem has just happened when I have to move the application to a new windows 2008 server.
What I have done is:
Changed the target from AnyCPU to x86 on server module, then tested it
on an BP machine and everything worked.
Moved the server and web module to Win 2008 server.
Installed the service and ran it, so far so good.
From the web site, I ran a query which failed with a null pointer
exception and something like this:
at
System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage
reqMsg, IMessage retMsg)
This is where my head started spinning. My code to talk to service is similar to this:
<application name="SHR">
<client url="tcp://localhost:8039">
<wellknown type="Package.dal.MyDAO, MyPackage" url="tcp://localhost:8039/SHR/MyDAO.rem"/>
</client>
<channels>
<channel ref="tcp client">
<clientProviders>
<formatter ref="binary" includeVersions="false"/>
<provider type="server, server"/>
</clientProviders>
</channel>
</channels>
</application>
I ran sql profiler and I can see the the class method that I am trying to call does execute completely, but for some reasons, it doesn't return anything. The class itself instantiates correctly as well as I have ran queries where I insert/delete and everything works, but when I need a dataset returned, it returns null even though I know its not null).
The issue occurs only in Win 2008 when I change the CPU to x86. I get another set of errors if I try to run the service without changing AnyCPU to x86.
Did you copy the web.config to the new IIS? It could be just a max size message mismatch between server and client
Ok here it is, It turned out to be a database user permission. The problem was that the error that I was getting from .net framework was absolutely crap and had no pointer that it was because of some type of user permissions. Thanks for every one who tried.
Following instructions here I have:
var connectionString = CloudConfigurationManager.GetSetting("StorageConnectionString");
But connectionString is null, here is my app.config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.5" />
</startup>
<connectionStrings>
<add name="StorageConnectionString"
connectionString="DefaultEndpointsProtocol=https;AccountName=storage;AccountKey=key" />
</connectionStrings>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Microsoft.Data.OData" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-5.2.0.0" newVersion="5.2.0.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
Had the same problem. Instead of using a connection string, use the configuration->appSettings->add key like this...
<configuration>
<appSettings>
<add key="StorageConnectionString" value="[ConnectionStringHere]" />
</appSettings>
</configuration>
As per documentation in MSDN http://msdn.microsoft.com/en-us/library/windowsazure/microsoft.windowsazure.cloudconfigurationmanager.aspx
Only configuration settings within the appSettings tag can be read by CloudConfigurationManager. If your configuration settings are within a different tag, calling GetSetting will return Null.
Well this works, even if the comment doesn't fit, because I do have a ref to CloudConfigManager:
If you are creating an application with no reference to Microsoft.WindowsAzure.CloudConfigurationManager, and your connection string is located in the web.config or app.config as show above, then you can use ConfigurationManager to retrieve the connection string. You will need to add a reference to System.Configuration.dll to your project and add another namespace declaration for it:
using System.Configuration;
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(
ConfigurationManager.ConnectionStrings["StorageConnectionString"].ConnectionString);
I had the same problem. I had updated the project to use Azure SDK 2.0. I updated NuGet packages for my web and worker roles, but the Azure project in Visual Studio was still on the old version.
To fix this, Right-Click on your Azure project and select Properties. Under the Application tab, you'll see a button to Update your Azure SDK.
Make sure all your references are in synch. There's the 2012-06 library and 2012-10 Set them to Copy Local = true and verify SDK version. I dealt with the exact same thing, drove me nuts.
This happened to me when I upgraded the Azure SDK to version 2.2.
To fix it I changed the packages.config to use a newer version of the Azure ConfigurationManager.
<package id="Microsoft.WindowsAzure.ConfigurationManager" version="2.0.1.0" targetFramework="net45" />
Based on my understanding, I'd like to point out that CloudConfigurationManager.GetSetting will look into web.config if you're running out of a cloud service. It will look into cscfg if you're inside a cloud service.
Please refer this
link.
Following this tutorial:
You can get configuration settings like this:
RoleEnvironment.GetConfigurationSettingValue("StorageConnectionString")
I got this after upgrading Azure SDK from 2.0 to 2.2. I was able to fix by:
Right-Clicking Azure project and selecting Properties. Update Azure SDK as per the Application tab. (Thanks to rattrick's answer).
Right click to Manage NuGet Packages. On the left click Updates and update WindowsAzure.ConfigurationManager.
I had the same problem (two times).
Even after restarting Visual Studio and after restarting the Azure emulator the CloudConfigurationManager.GetSetting("SettingName") returns null.
I was sure that it has worked before and I had the latest SDK.
So the solutions was restarting my PC and after that CloudConfigurationManager.GetSetting("SettingName") returns the right value.
I got the same issue this am after revisiting my Azure solution (Web + Worker role) to update it for Azure 2.5. Reviewing the help for CloudConfigurationManager.GetSetting, if its running under a cloud platform (Azure) it reads from the ServiceConfiguration.csfg, if running as a .net web app, reads from app or web.config.
So my fix was to simply change the start up project back to the Azure cloud project, not the Web project.
I was getting null because it was hosted in the wrong platform and reading from the .config files with no settings.
(Doh!)
It is an old thread but I wanted to share my solution if issue is not resolved by above mentioned methods then make sure that Azure Storage Emulator is running when you run the application; at least for me this happened. For me I had to create a class to handle emulator issue as mentioned here...
http://blog.simontimms.com/2013/08/28/configuration-settings-in-an-azure-worker-role/
class ConfigurationProvider
{
private static string GetStorageConnectionString(string name)
{
try
{
return RoleEnvironment.GetConfigurationSettingValue(name);
}
catch (SEHException)
{
return System.Configuration.ConfigurationManager.ConnectionStrings[name].ConnectionString;
}
}
public static string StorageConnectionString()
{
return GetStorageConnectionString("StorageConnectionString");
}
public static string DefaultConnection()
{
return GetStorageConnectionString("DefaultConnection");
}
}
I had quite similar problems. I updated from Azure SDK 2.0 to 2.2 - during this process I used the NuGet Manager to update the Microsoft.WindowsAzure.Storage to the latest. The PackageManager automatically took Microsoft.WindowsAzure.Configuration to 1.8.0.0. I was not able to get this running (it was for .Net 2.0!?). After I manually set all References to
Microsoft.WindowsAzure.Storage 2.1.0.0
Microsoft.WindowsAzure.Configuration 2.0.0.0
everything worked.
I think this is because of the way CloudConfigurationManager.GetSetting loads the assembly and calls the funktions (via reflection).
Same here after upgrading Azure SDK from 2.2 to 2.3.:
Right-Click the Azure project select Properties. In the Application tab click "Upgrade..." (Thanks to rattrick's answer).
Then there was one more error to resolve:
Trying to run the Azure Project in the Compute Emulator threw an exception:
System.Configuration.ConfigurationErrorsException was unhandled
Message: An unhandled exception of type 'System.Configuration.ConfigurationErrorsException' occurred in Microsoft.WindowsAzure.ServiceRuntime.dll
Additional information: konnte nicht erstellt werden.
In the "Error List" Window of VS2013 there was the following Warning:
Found conflicts between different versions of the same dependent assembly. In Visual Studio, double-click this warning (or select it and press Enter) to fix the conflicts; otherwise, add the following binding redirects to the "runtime" node in the application configuration file: C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets 1635
I let VS resolve this warning and everything worked fine.
This worked for me...
using System.Configuration;
...
var connectionString = ConfigurationManager.ConnectionStrings["StorageConnectionString"].ConnectionString;
I had the same problem. None of the advices worked for me, but the "issue" was straightforward. One simple has to understand how this class works.
It does not go into your app.config / web.config or wherever you store your application settings. CloudConfigurationManager works with ServiceConfiguration.*.cscfg and ServiceConfiguration.csdef. The .csdef must contain a definition of the setting, but not its value under the ConfigurationSettings section. The settings themselves sit in .cscfg files (under the same section but including the value; I suppose the reason for the double definition is to make sure both the cloud and the local configurations have the same settings).
You can set these either by right-clicking your role in Visual Studio and selecting Properties -> Settings (in case of StorageConnectionString, simply pick "Your subscription", if your storage account is connected to the cloud service), or by editing them manually. If you mess up the settings, you'll get an exclamation mark icon.
Simple as that.
Was getting a null value with when passing a literal string as well after installing Azure SDK 2.6 (was working before).
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(ConfigurationManager.ConnectionStrings["AzureStorage"].ConnectionString);
Replaced the literal string and it worked fine.
string connectionStr = "AzureStorage";
var connectionstring = ConfigurationManager.ConnectionStrings[connectionStr].ConnectionString;
CloudStorageAccount storageAccount = CloudStorageAccount.Parse(connectionstring);