I have a really strange issue where I have a project based nuget feed which one pipeline publishes to, which works fine, then another pipeline which needs to restore a project which uses this nuget feed.
The problem is I have followed all the instructions on this such as:
Make sure Build Service has permissions
Make sure NuGetAuthenticate 0 or 1 is called
Ensure there is a nuget.config with the feed included
So for example the nuget.config looks like:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<clear />
<add key="nuget" value="https://api.nuget.org/v3/index.json" />
<add key="azure-feed" value="http://pkgs.dev.azure.com/<org>/<project>/_packaging/<feed-name>/nuget/v3/index.json" />
</packageSources>
</configuration>
Then the pipeline section looks like:
steps:
- task: NuGetAuthenticate#0
- task: DotNetCoreCLI#2
displayName: dotnet restore
inputs:
command: restore
nugetConfigPath: 'nuget.config'
feedsToUse: config
This all works fine in the IDE (VS and Rider) and the pipelines that publish and read the nuget package are all in the same azure devops project as the feed.
When the build runs I see the authenticate step run:
Setting up the credential provider to use the identity '<project> Build Service (<org>)' for feeds in your organization/collection starting with:
https://pkgs.dev.azure.com/<org>/
https://<org>.pkgs.visualstudio.com/
Which is all correct and is pointing to the correct feeds, but when the restore runs the error below occurs:
error NU1301: Unable to load the service index for source http://pkgs.dev.azure.com/<org>/<project>/_packaging/<feed-name>/nuget/v3/index.json.
All the articles online say to try switching to NuGetAuthenticate#0 or enabling higher level settings to allow build service project scopes to not be constrained, as well as confirming all permissions are correct, none of that has solved the problem.
The issue here is that the feed in the nuget.config file is using http not https and for some reason the nuget authenticate task will ONLY authenticate the https url not the unsecure http one which the IDEs work fine with.
So changing:
<add key="azure-feed" value="http://pkgs.dev.azure.com/<org>/<project>/_packaging/<feed-name>/nuget/v3/index.json" />
to:
<add key="azure-feed" value="https://pkgs.dev.azure.com/<org>/<project>/_packaging/<feed-name>/nuget/v3/index.json" />
Fixes it all and it works, this was never mentioned as a possible solution online so I thought it prudent to put here for any future generations who have the same issue.
I'm currently trying to setup Application Insights for a WebApi running on Service Fabric. While this is super easy to configure for a .NET Core application, it seems to be way more complicated for a .NET Classic application.
The official docs do only contain a rather primitive way to setup Application Insights by clicking through Visual Studio - which in the end did not work for me (it tried to add a reference to the .NET Core Nuget Package for Application Insights).
Important facts about the project
TargetFramework is net461
The application is running on Service Fabric 6.5.664.9590
What i tried so far
In my project, i referenced these three nuget packages:
Microsoft.ApplicationInsights.Web
Microsoft.ApplicationInsights.DependencyCollector
Content of the ApplicationInsights.config (I added it to the root of the project)
<?xml version="1.0" encoding="utf-8"?>
<ApplicationInsights xmlns="http://schemas.microsoft.com/ApplicationInsights/2013/Settings">
<TelemetryModules>
<Add Type="Microsoft.ApplicationInsights.Web.RequestTrackingTelemetryModule, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.DependencyCollector.DependencyTrackingTelemetryModule, Microsoft.AI.DependencyCollector" />
</TelemetryModules>
<TelemetryInitializers>
<Add Type="Microsoft.ApplicationInsights.Web.OperationNameTelemetryInitializer, Microsoft.AI.Web" />
<Add Type="Microsoft.ApplicationInsights.Web.OperationIdTelemetryInitializer, Microsoft.AI.Web" />
</TelemetryInitializers>
</ApplicationInsights>
In Startup.cs, i overwrite the instrumentation key - because it differs based on the environment the application is running on (read more about that here)
public IServiceProvider ConfigureServices(IServiceCollection services)
{
services.AddMvc();
services.AddAuthentication(...);
TelemetryConfiguration.Active.InstrumentationKey = _applicationInsightSettings.InstrumentationKey;
}
However - no request traces or any other information is sent to Application Insights. What am I missing?
Edit
The configuration part is working - when debugging the app, I can see that the TelemetryInitializers property in TelemetryConfiguration.Active is set to what i configured in ApplicationInsight.config. But nothing is being sent to ApplicationInsights and there are also no errors or exceptions happening.
My solution
Turns out the easiest solution was to get rid of the net461 target framework constraint. A dependency I used (a NuGet package) was limiting me to use net461. Once I got rid of that dependency, and moved the application to .NET Core and boom - everything works just magically.
My cloud service has the following config:
<?xml version="1.0" encoding="utf-8"?>
<ServiceConfiguration ...>
<Role name="...">
<ConfigurationSettings>
<Setting name="MyCertThumbprint" value="AB687DC9F63D51AE6E9522B86B97EFD15F55EA42" />
</ConfigurationSettings>
<Certificates>
<Certificate name="MyCert" thumbprint="AB687DC9F63D51AE6E9522B86B97EFD15F55EA42" thumbprintAlgorithm="sha1" />
</Certificates>
</Role>
</ServiceConfiguration>
See the redundance?
I want to get rid of MyCertThumbprint config. Is there an Azure API that gives me access to the thumbprint of MyCert? Or maybe the X509Certificate2 instance itself (i.e. without having to search for it using X509Store) ?
Sure - if you know other information about the certificate, you can use any of the X509FindType Enumerations with X509Certificate2Collection.Find Method. Unfortunately, the Certificates section of the ServiceConfiguration is for locating the certificate in the Cloud Service certificate store and installing that certificate on the VMs associated with the Role you are deploying. There is no API to access the section directly. So your choice is to hard code something like the certificate subject name or the thumbprint and hope it doesn't change, or add a setting like you've demonstrated in your code sample that is configurable with each deployment.
The ConfigurationSettings section mirrors the appSettings section in the web.config file and when used in conjunction with CloudConfigurationManager.GetSetting("settingsKey") with look first in the ServiceConnfiguration then in the web.config for application settings, allowing you to un local in an emulator or just IIS express and achieve the same functionality. So we duplicate the settings in both ServiceConfiguration and web.config.
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);
I have followed this tutorial to create the first azure application
http://msdn.microsoft.com/en-us/WAZPlatformTrainingCourse_IntroToWindowsAzureLabVS2010
Because after deployment its not working on the following url
http://24fb8b6a055d4ab2a556218f62d6dbe1.cloudapp.net/
I found the following link helpful to connect via remote desktop to be able to see the error:
http://wely-lau.net/tag/remote-desktop/
However, after following all steps, I get the following error
Remote Desktop can’t connect to the remote computer for one of these
reasons:
1) Remote access to the server is not enabled
2) The remote computer is turned off
3) The remote computer is not available on the network
Make sure the remote computer is turned on and connected to the
network, and that remote access is enabled.
In:
ServiceConfiguration.Cloud.cscfg
I have this contents
<?xml version="1.0"?>
<ServiceConfiguration serviceName="GuestBook" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration">
<Role name="GuestBook_WebRole">
<Instances count="1" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=luisvalenciaguestbook;AccountKey=x" />
<Setting name="DataConnectionString" value="DefaultEndpointsProtocol=https;AccountName=luisvalenciaguestbook;AccountKey=x" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="levalencia" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="x" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2012-12-16T23:59:59.0000000+01:00" />
</ConfigurationSettings>
<Certificates>
<Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="x" thumbprintAlgorithm="sha1" />
</Certificates>
</Role>
<Role name="GuestBook_WorkerRole">
<Instances count="1" />
<ConfigurationSettings>
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="DefaultEndpointsProtocol=https;AccountName=luisvalenciaguestbook;AccountKey=x" />
<Setting name="DataConnectionString" value="DefaultEndpointsProtocol=https;AccountName=luisvalenciaguestbook;AccountKey=x" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.Enabled" value="true" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountUsername" value="levalencia" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountEncryptedPassword" value="x" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteAccess.AccountExpiration" value="2012-12-16T23:59:59.0000000+01:00" />
<Setting name="Microsoft.WindowsAzure.Plugins.RemoteForwarder.Enabled" value="true" />
</ConfigurationSettings>
<Certificates>
<Certificate name="Microsoft.WindowsAzure.Plugins.RemoteAccess.PasswordEncryption" thumbprint="x" thumbprintAlgorithm="sha1" />
</Certificates>
</Role>
</ServiceConfiguration>
By default Remote Desktop for Azure uses the usual TCP port 3389: you'll need to have this enabled outbound at your corporate firewall.
An alternative approach to setting up Remote Desktop through the configuration files directly or through Visual Studio is to use the Azure Management Portal to modify them temporarily. This is rather easier and somewhat less error prone, especially where certificates are concerned.
Sign in to the management portal as usual, and choose "Hosted Services". Then find the service you'd like to configure.
The next step is to configure the Web Role or Worker Role to allow Remote Desktop connections: this will adjust the configuration file for the service, so any changes here will be lost when you next upgrade or reimage. Select the role, then in the toolbar ensure "Enable" is checked on, and choose Configure:
You'll be prompted for the username, password, certificate and expiry time.
Choose OK. If you've made changes to the configuration it can take a little while (sometimes several minutes) for them to be applied.
Once the instances are marked as "ready" again, you can then select one and choose Connect:
This will download a file with the extension .rdp, which you can then open to connect to the remote host. (You will most likely see some security warnings when you do so.)
If you still see the warning about being unable to connect to the remote host then there are a couple of things to explore: certificates and firewall issues. In my experience the "manual" process, configuring the remote desktop settings in Azure through the portal, usually gets around any issues with certificates.
Firewall issues are harder to resolve. You may find that using Windows Azure Connect -- which in essence creates a secure VPN connection from your PC to the Azure instances -- allows you to access the Azure host directly, tunnelling across your corporate firewall.
If you are exposing a https endpoint, make sure you also expose an http endpoint. This solved the same issue for me with a data service I am hosting in a webrole.
All the above didn't work for me.
Enter your credentials, prefixed with . E.g. “\maarten”. This is done to strip off the Windows domain from the credentials entered.
Its somehow strange that is not documented anywhere and it should be stripped off by the windows azure RD manager !
I had this problem and nothing worked, I couldn't Remote Desktop in even though the role was fully working.
It turns out there is a known issue with Azure SDK 1.7 and 1.8. Here is the info I received from Microsoft:
A timing issue in a role startup in SDK versions 1.7 and 1.8 sometimes causes a firewall rule required by the Remote Forwarder Service to be deleted. Restart of the service will correct the problem and recreate the firewall rule but this is not a persistent fix. Any redeployment or restart of the role instance may cause the problem to reoccur.
Work Around:
Azure application developers can implement a custom startup task that refers to a *.cmd file (e.g. RemoteForwarderConfig.cmd) as described below. This will ensure a firewall rule is created that opens ports for the Remote Forwarder Service. This startup task should be added to the role designated for running the remote forwarder.
Documentation on startup tasks is available at http://msdn.microsoft.com/en-us/library/windowsazure/gg456327.aspx
Example task config:
<Task commandLine="RemoteForwarderConfig.cmd" executionContext="elevated" taskType="background"></Task>
Example task cmd file contents:
#echo off
netsh advfirewall firewall add rule name="RemoteForwarderService custom rule" description="Allow incoming connections to the remote forwarder" dir=in protocol=tcp program="%ProgramFiles%\Windows Azure Remote Forwarder\RemoteForwarder\RemoteForwarderService.exe" action=allow enable=yes
I had this issue and couldn't figure it out.
Turned out the password wasn't complex enough however it didn't inform me of this at any point. Adding a more complex password and logging in with \YourUsername sorted it for me!