So I have installed the very latest version of SlowCheetah (3.0.61.18192 as of the time of this post) and I've added a "Test" build configuration alongside the "Debug" and "Release" build configurations.
Then I was able to add "Web.Test.config" to an already existing collection of "Web.Debug.config" and "Web.Release.config".
In my Web.Test.config I am trying to replace the entire 'configuration' section by telling SlowCheetah to xdt:Transform="Replace" the entire configuration section (at the top of the file).
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform" xdt:Transform="Replace">
To verify that my "Web.config" indeed got transformed to whatever's in "Web.Test.config" I've added a simple app setting to "Web.Test.config".
<appSettings>
<add key="configFile" value="IIS.config"/>
</appSettings>
Then on page load I try to read this setting and show if it has been found or not:
string setting = WebConfigurationManager.AppSettings["configFile"];
if (string.IsNullOrEmpty(setting))
{
lbl1.Text = "Not found.";
}
else
{
lbl1.Text = "Found!";
}
However when I select "Test" build configuration and hit F5 to debug I get "Not found." message.
So my question is why isn't SlowCheetah transforming my Web.config to Web.Test.config on the fly when I hit F5 and not picking up that custom app config setting? Basically I am trying to use SlowCheetah to debug my code with custom "Test" configuration by asking it to pickup the settings from "Web.Test.config" instead of regular "Web.config". (I also verified that my C# code is reading the configuration variable properly).
What am I doing wrong? or am I not understanding something? According to this link, SlowCheetah is supposed to support this: https://marketplace.visualstudio.com/items?itemName=WillBuikMSFT.SlowCheetah-XMLTransforms
Thanks.
Related
I have a Chrome Extension in development, locally which is a React application.
I have set up a CI/CD pipeline so that the React app is built with yarn build to produce the dist directory containing the app files and the manifest.json. The pipeline then uses this npm package to create the .crx file and upload it to a public storage location along with the update.xml file which has been updated with a new version number and URL to the new .crx file.
I created a private key (key.pem) locally and stored in a key vault so that the "packing" job in CI pipeline uses the same private key each time. The public key has been added to the manifest.json so that the app ID stays the same each time.
Update2.xml
<?xml version='1.0' encoding='UTF-8'?>
<gupdate xmlns='http://www.google.com/update2/response' protocol='2.0'>
<app appid='blahblahooaejaldnohkhmaedknkfogn'>
<updatecheck codebase='https://mypubliccrxstorage.blob.core.windows.net/crx/myapp-1.0.20210702.22.crx' version='1.0.20210702.22' />
</app>
</gupdate>
manifest.json
{
...
"manifest_version": 2,
"version": "1.0.20210702.22",
"key": "<my-public-key",
...
"update_url": "https://mypubliccrxstorage.blob.core.windows.net/crx/update2.xml"
}
Steps to install and update:
Go to chrome://extensions/ > developer mode > load unpacked > select local dist directory.
The unpacked extension appears in the list of extensions with app id: blahblahooaejaldnohkhmaedknkfogn
Select the extension and click "Update"
Expected result:
Chrome queries the remote update.xml file, sees a version later than the initially installed version, downloads and installs the new crx file from the specified location.
Actual result:
The extension is not updated.
Note: I downloaded the crt generated by the CI/CD from the storage location and uploaded it here. The public key shown by that online tool matches the value of key in the manifest.json and the calculated app id matches the one in update.xml.
To dig a little deeper I opened Fiddler4 and sniffed the calls made by Chrome. Although I don't understand everything, part of one of the responses was:
<?xml version="1.0" encoding="UTF-8"?><gupdate xmlns="http://www.google.com/update2/response" protocol="2.0" server="prod"><daystart elapsed_days="5296" elapsed_seconds="28389"/><app appid="mgndgikekgjfcpckkfioiadnlibdjbkf" status="error-unknownApplication"/><app appid="apbllhlpimnkljppmmdbiipfbjjimjgj" cohort="1::" cohortname="" status="ok"><updatecheck _esbAllowlist="false" status="noupdate"/></app></gupdate>
That "app id" is not mine (or is that the Chrome app id?), but the status of "error-unknownApplication" perhaps gives some hint as to what is going on.
No protection setting in Chrome allows an extension to update. This setting also allows to drag and drop .crx into chromium extensions.
Installing the chrome extension by "Load unpacked" button at chrome://extensions "ties" the install to the file system and doesn't allow for updates.
The extension needs to be installed via the .crt file for updating to work.
The ability to do this has been removed in Chrome for security reasons.
However you can use Chrome's developer version, Chromium to install the .crt file by dragging and dropping. Installing in this way allows the extension to be updated using the method in the original question (if everything is configured correctly).
This workaround was acceptable in my case.
I need to redesign one of the system's module using Asp.Net Core and host it inside IIS server. So, I just need to replace already existing ASP.NET Web Forms app with the .Net Core based API. But the tricky part here that I still have to use upper level web.config file(s) and fetch configuration parameters from it.
I did brief research and found out that it may be a problem cause the configuration mechanism was changed and it's not recommended to use XML based we.config or app.config any more and I should use app.settings instead: https://learn.microsoft.com/en-us/aspnet/core/fundamentals/configuration/?view=aspnetcore-2.2
I found this very nice article https://wildermuth.com/2018/04/15/Building-a-NET-Core-Configuration-Source about how to build custom configuration source and provider and now I can even extract app setting from the local web.config file but still experiencing the problem with getting access to the upper level web.config file.
When I do this
.ConfigureAppConfiguration((hostingContext, config) =>
{
config
.AddWebConfig("web.config", optional: true)
.AddJsonFile("appsettings.json", optional: true);
})
I can successfully find and parse web.config file, but when I try to find web.config in an upper level like this
.ConfigureAppConfiguration((hostingContext, config) =>
{
config
.AddWebConfig("..\\web.config", optional: false)
.AddJsonFile("appsettings.json", optional: true);
})
I get en error message
System.IO.FileNotFoundException: 'The configuration file
'..\web.config' was not found and is not optional.'
Any recommendations about how to get access to upper level web.config file would be very much appreciated!
Unfortunately I can't skip this part and this is one of the client's business requirements.
I recently deployed an ASP.Net Web API project to our Azure App Service test slot but started receiving an error when making requests to the API endpoints. Through remote debugging, it became clear that the app was extracting my dev connection strings from the deployed web.config file.
The connection strings are supposed to come from the Application Settings we set up via the Azure Portal - and, in previous deployments, they were - but that's not the case.
Why would this happen and what can be done to ensure the correct behaviour occurs? We absolutely don't want our production database secrets being put into GIT via the web.config...
I recently experienced the same problem and fixed it:
In Azure App Services, the machine-wide web.config file is located at D:\Windows\Microsoft.NET\Framework64\v4.0.30319\Config\web.config.
This file differs to a normal machine-wide web.config file because it has this extra element:
<system.web>
...
<compilation>
<assemblies>
<add assembly="EnvSettings, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
...
</assemblies>
</compilation>
</system.web>
The EnvSettings.dll assembly is located inside D:\Program Files\IIS\Microsoft Web Hosting Framework (unfortunately this directory is access-controlled and I can't get into it).
But EnvSettings.dll is mirrored in the GAC, so I was able to copy it from there.
Inside EnvSettings.dll is an [assembly: PreApplicationStartMethod] attribute that runs a method in EnvSettings.dll which copiesthe APPSETTING_ and database connection-string settings from Environment Variables into the .NET Framework ConfigurationManager.AppSettings and ConfigurationManager.ConnectionStrings collections.
Note this copying only happens once (during application startup), and only in the first AppDomain - so if you have other AppDomain instances in your application they won't see the updated ConfigurationManager.
Therefore, if you see that your Azure Portal configuration settings for your App Service are not being used when you dump your ConfigurationManager, then the following is likely happening:
You used <clear /> in your <compilation><assemblies> element, which stops EnvSettings.dll from being loaded at all.
In which case you need to either add back the <add assembly="EnvSettings... element from above to your own web.config, or find some other way to load it.
I don't recommend saving EnvSettings.dll locally and adding an assembly reference to your project, as EnvSettings.dll is part of the Microsoft Web Hosting Framework.
Or you have code that is clearing or resetting ConfigurationManager after EnvSettings populates it for you.
Or something else is going on that I have no idea about!
As an alternative to having EnvSettings.dll copy your settings over, another option is to copy the environment-variables over yourself - and as you control the code that does this it means you can call it whenever you need to (e.g. if you ever reset them).
Here's the code I used:
public static class AzureAppSettingsConfigurationLoader
{
public static void Apply()
{
foreach( DictionaryEntry environmentVariable in Environment.GetEnvironmentVariables() )
{
String name = (String)environmentVariable.Key;
String value = (String)environmentVariable.Value;
if( name.StartsWith( "APPSETTING_", StringComparison.OrdinalIgnoreCase ) )
{
String appSettingName = name.Substring( "APPSETTING_".Length );
ConfigurationManager.AppSettings[ appSettingName ] = value;
}
else if( name.StartsWith( "SQLAZURECONNSTR_", StringComparison.OrdinalIgnoreCase ) )
{
String csName = name.Substring( "SQLAZURECONNSTR_".Length );
ConfigurationManager.ConnectionStrings.Add( new ConnectionStringSettings( csName, value, providerName: ""System.Data.SqlClient" ) );
}
}
}
}
See my sample here: http://mvc5appsettings.azurewebsites.net/
// My web.config also has a "HERO_TEXT" key in
// that reads "Value from web.config"
string hero = ConfigurationManager.AppSettings["HERO_TEXT"];
Wiki page on App Settings for .NET:
https://github.com/projectkudu/kudu/wiki/Managing-settings-and-secrets
As already mentioned here, make sure you have that App Setting in the right slot.
As I know, the settings in Azure portal will override existing setting in Web.config. So If you want to ignore the Azure Application settings in portal and use Web.config instead. I am afraid you need to configure the settings in web.config, and remove the same key/pair in Azure portal.
I've got an azure webjob, that has some appsettings for api keys etc.
I've also got a bunch of PRODUCTION azure app settings (specified in the portal), that should override my webjob config appsettings.. But they don't.
For my website, they work as expected, and all is fine. For the webjobs however, they just get completely ignored, and my app settings from the config are used instead.
Is this a bug in azure? All the docs suggest that this should work.
EDIT
I found this blog all about using CloudConfigurationManager.GetSetting so I've implemented that and it still won't work - still using the settings that are defined in web job's app settings file :(
Thanks
So it looks like I've found a bug!
It's because my AppSettings were referenced from another file, like this (in app.config):
<AppSettings file="appsettings.config"/>
This basically breaks azure's config management.
Use
"D:\home\site\wwwroot\" to create an absolute path to files inside your website.
inside your WebJob to point to any file inside your wwwwroot directory. Using the Absolute path with D:\home\site\wwwroot\appsettings.config should fix you website.
Did you set your settings only in the Web.config file or did you set them in the portal or using the VS "Website Settings" tooling? You need to set the WebJobs-related settings at that level, not just in the Web.config. Once you do that, restart your site, and the settings should be there.
I had a similar problem but for me it was that we set the "is_in_place" settings.job value to true. I guess when it's in place, it doesn't update the config file with the settings. We didn't have a strict requirement that it run in place, so removing that setting fixed the problem for us.
I have a similar problem with several web jobs sharing a common settings file. It would be inconvenient to duplicate the settings in each job.
Someone mentioned using configSource= instead of file= in the app.config to reference the external config settings file. I tried this, and it appears that it now works as expected. The settings are being taken from the Portal App Settings instead of the file now.
Fortunately, the settings for the web jobs all come from the external file. The use of file= allowed me to use additional per-app settings other than just those in the file, but fortunately I don't need to do that.
A workaround to this problem is to place the settings inline in the AppSettings tag of the Web.config like this.
<AppSettings>
<add key="host" value="someHost" />
</AppSettings>
Azure App Service Application Settings are persisted in the Environment Variables. Go to the Azure Portal add your application settings or connection string values. Then, you can check out the environment variables of your app service at https://sitename.scm.azurewebsites.net
If you want your webjobs to share those settings, in your webjob project, create a appsettings.json:
{
"APPSETTING_AzureWebJobsDashboard": "",
"APPSETTING_AzureWebJobsStorage": "",
"SQLAZURECONNSTR_xxx": ""
}
In your Main() method
private static void Main(string[] args)
{
var builder = new ConfigurationBuilder()
.SetBasePath(Directory.GetCurrentDirectory())
.AddJsonFile("appsettings.json", optional: false, reloadOnChange: true)
.AddEnvironmentVariables();
var configurations = builder.Build();
var services = new ServiceCollection()
.AddDbContext<ApplicationDbContext>(options =>
options.UseSqlServer(configurations["SQLAZURECONNSTR_xxx"]),
ServiceLifetime.Transient)
.BuildServiceProvider();
var host = new JobHost(new JobHostConfiguration
{
DashboardConnectionString = configurations["APPSETTING_AzureWebJobsDashboard"],
StorageConnectionString = configurations["APPSETTING_AzureWebJobsStorage"]
});
host.RunAndBlock();
}
This is simpler than trying to figure out the path to the website config on the app service
I'm implementing the combined web/worker role scenario as described here where you simply add the following to your worker role:
public override void Run()
{
// This is a sample worker implementation. Replace with your logic.
Trace.WriteLine("WorkerRole1 entry point called", "Information");
while (true)
{
Thread.Sleep(10000);
Trace.WriteLine("Working", "Information");
}
}
The problem, as noted in the post's comments, is that this worker process cant read web.config so you have to add an app.config. It is also noted that app.config does not get deployed automatically.
So my question is how do I configure my project so app.config will get deployed?
I've added app.config to my project, set the Build Action to "Content", and "Copy always"
THIS WORKS FINE IN THE EMULATOR, but not when deployed to Azure.
Note: I noticed in the emulator a projectname.dll.config is created, but not when deployed to Azure.
I'm using VS2010, Windows Azure Tools 2011
I know some will suggest using the .cscfg file instead, but many of my components get their settings from web.config/app.config:
Elmah, Transient Fault Handling Client, Diagnostics, Email, etc...
Please read thoroughly this blog post. It explains in great details what is happening in Windows Azure Web Role with Full IIS.
What you need to do, is to add a WaIISHost.exe.config file (with copy to output = copy always). And put all the configurations you need in that file. This is because, your code (RoleEntryPoint) lives in WaIISHost.exe process, and not your pdojectName.dll process.
For me using Azure SDK 1.8 and deploying my Web Worker Role from the Visual Studio using publish, I had to include a config file, named. ProjectName.Dll.config with my settings. The configuration from app.config is not picked up by the web role when running in windows azure. And the app.config file is not converted into a ProjectName.Dll.config and added automatically to the bin folder of the deployment package, so you have to create it by hand and set it to copy always.
I'm using Azure SDK 2.0 and OS Family 3, and has been very confused about this. So I created a MVC 4.0 website with all 4 config files suggested in various answers. That is:
Web.config
App.config
WaIISHost.exe.config
[AssemblyName].dll.config
All but Web.config was set to "Copy if newer".
In the configs file I wrote:
<appSettings>
<add key="AppSettingFile" value="[NameOfConfigFile]"/>
</appSettings>
In the WebRole.cs I have the following code:
public class WebRole : RoleEntryPoint
{
public override void Run()
{
string appSetting = ConfigurationManager.AppSettings["AppSettingFile"] ?? "No config file found";
Trace.TraceInformation("Config file: " + appSetting);
while (true)
{
...
}
}
}
Result when deployed with 4 .config files:
"Config file: App.config". So App.config must be the answer, right?
Wrong! Result when deployed with only Web.config and App.config:
"Config file: No config file found". Hmm wierd.
Result when deployed with Web.config, App.config and [AssemblyName].dll.config:
"Config file: [AssemblyName].dll.config". So [AssemblyName].dll.config must be the answer, right?
Wrong! Result when deployed with only Web.config and [AssemblyName].dll.config:
"Config file: No config file found". WTF!
Result when deployed with only Web.config and WaIISHost.exe.config:
"Config file: No config file found".
Result when deployed with Web.config, App.config and WaIISHost.exe.config:
"Config file: No config file found". WTF!
So my conclusion is that you need to have 3 or 4 config files to be able to configure the Worker role of a Web project.
This is clearly a bug. Personally I think the intention from MS was to change from WaIISHost.exe.config to App.config (to align with Worker Roles and .NET in general). But App.config is only used when all 4 .config files exists.
So for now I'm having Web.config and both App.config and [AssemblyName].dll.config, and they contain exactly the same.
Hopefully going forward with Azure SDK 2.x we can use only App.config and Web.config.