I have a ASP.NET MVC 4 web project
WebUI
that references a ASP.NET 4 Code Library
DAL
The Code Library has a reference to the SlowCheetah 2.5.5 NuGet package and is setup with several transformations for it's App.Config.
The WebUI is using the normal Web.Config transformations but I have also added a reference to SlowCheetah as a test for my problem but it didn't change my issue.
When I publish using
MS Web Deploy
in Visual Studio 2012 or when I publish straight to
File System
using a QA configuration the correct Web.QA.config is put in the root of my website, however the referenced class library configuration is not working, I get a sql connection error on the home page which alerts me that the correct App.Config transformation is most likely not being used for the referenced DAL project.
I thought this would be a .dll.config file in the bin folder for the WebUI, but I am not too sure as I have this working on another web server where I manually changed the default App.Config and Web.Config files and there is no .dll.config file present in the root bin directory of the website.
Anyone know how to get this working?
UPDATE:
Examples below:
DAL Code Library project App.Config
<configuration>
<configSections>
</configSections>
<connectionStrings>
<add name="DAL.Properties.Settings.DefaultConnection" connectionString="Data Source=(local);Initial Catalog=MyDB;Integrated Security=True;" />
</connectionStrings>
</configuration>
Part of Web.Config from my WebUI project
<connectionStrings>
<add name="WebUI.Properties.Settings.DefaultConnection" connectionString="Data Source=(local);Initial Catalog=MyDB;Integrated Security=True;" />
</connectionStrings>
I use a Settings.settings file for each project.
How can I merge the App.Config connection into my Web.Config so that it is transformed during publishing? preferably I would want it to just use the one connection when publishing to the web.
At the moment the DAL referenced project works on the web application if I set the app.config correctly (which only makes some sense to me since its a referenced .dll).
Does adding this DAL.Properties.Settings.DefaultConnection connection to my web.config replace the one the DAL is using?
All of your settings for the web application will come from the web.config file - the app.config won't be used or deployed with the web app. Most likely, that config is there because you are using Entity Framework and that's where the EDMX functionality stores it's connection string. If you put the connection string in the web.config (and use the appropriate config transformations), you should be good.
Related
I'm migrating an ASP.NET Web API solution that uses the .NET Framework 4.6.1 to ASP.NET Core 5 / .NET Framework 5. Besides the Web API project there is an MSTest based testing project that shares the connection string information with the Web API project. This looks as follows:
The Web API project has a Web.config file containing the following code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<connectionStrings configSource="bin\ConnectionInfo.config" />
...
</configuration>
The MSTest based project has an App.config file containing the following code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.6.1"/>
</startup>
<connectionStrings configSource="ConnectionInfo.config"/>
</configuration>
Hence, both of the above files reference ConnectionInfo.config which contains the actual connection string and looks as follows:
<connectionStrings>
<add name="MyConnectionString" connectionString="the connection string" />
</connectionStrings>
That setup ensures that I have a single point where I need to change the connection string to point the application to another database.
Eventually, I retrieve the connection string in the test database and pass it to my DatabaseManager which provides functionality to create and reset the database:
string connectionString = ConfigurationManager.ConnectionStrings["MyConnectionString"].ConnectionString;
_databaseManager = new DatabaseManager(connectionString);
Now, after migrating the Web API project to ASP.NET Core 5 the Web.config is replaced with an appsettings.json file. There's one such file for every environment and each contains the connection string for that environment.
Is there a way to share the corresponding connection string with the test project somehow? I don't want to load the appsettings.json manually in that project but hope for a built-in mechanism. Is there anything that might help?
You can use the existing app.config to hold connection string like those in .NET Framework in .NET 5.0 by adding nuget package of System.Configuration.ConfigurationManager to the unit test project, and use the ConfigurationManager.ConnectionStrings as before in .NET Framework.
The latest stable version is v5.0.0.
See also the nuget page https://www.nuget.org/packages/System.Configuration.ConfigurationManager/5.0.0
and the docs:
https://learn.microsoft.com/en-us/dotnet/api/system.configuration.configurationmanager.connectionstrings?view=windowsdesktop-5.0
One thing is to be sure, the System.Configuration.ConfigurationManager nuget package is mostly Windows specific, and in the docs it is included as part of "Windows Desktop" of .NET 5.0, not the full cross platform of .NET 5.0.
In order to read the connection string stored in the main project's appsettings.json from the test project I added the NuGet package Microsoft.Extensions.Configuration.Json to it.
Then, I ensured that the appsettings.json file is copied to the output directory by the main project which can be done as follows in the .csproj file:
<ItemGroup>
<None Include="appsettings.Development.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
<None Include="appsettings.json">
<CopyToOutputDirectory>Always</CopyToOutputDirectory>
</None>
</ItemGroup>
Finally, in the test project I obtain the connection string by reading the appsettings.json file as follows:
protected static readonly string _connectionString = new ConfigurationBuilder()
.SetBasePath(AppContext.BaseDirectory)
.AddJsonFile("appsettings.json", false, true)
.Build()
.GetConnectionString("ConnectionStringKeyName");
Problem
A .lic file which is in the root of the ASP.NET Web Application is not deployed to Azure Web App during VS 2015 Publish operation. The .lic file set as "Content"
Context
I have a component in my ASP.NET MVC which requires its .lic file in the web application root.
I am using VS 2015 Built in Publish to deploy my web app to Azure as an Azure Web App Service.
The .lic file is added to the ASP.NET MVC Web project as a "Content".
However the .lic file is not published. (checked via FTP)
Question
How can I publish this .lic file to the Web App Service root? (of course I can manually copy it via ftp, but that's not a solution in long term)
More Diagnostics
I've created a Hello.txt file in my project in the root. All settings the same, the Hello.txt is published. It seems that the VS 2015 Publish ignores .lic files... Is it possible? How to overcome?
Add to web.config:
<system.web>
<compilation>
<buildProviders>
<remove extension=".lic"/>
<add extension=".lic" type="System.Web.Compilation.ForceCopyBuildProvider"/>
</buildProviders>
</compilation>
</system.web>
I have an ASP.NET Web Application project that connects to a remote database via the Entity Framework. During debugging (eg running the project on my local computer), the IP address to the database is different than during release (eg after uploading the project to my webserver and running it from the browser). Until now I have always manually changed the database connection string in the Web.config file to switch between the two (basically I had to connection strings, one named 'Debug' and one 'Release' and I just swapped around the names whenever I deployed).
Now I just noticed that it should be possible to let this happen automatically via the Web.config Transformation Syntax where you put the modified connection string in the Web.Release.config version and it should then use that when the DLL is built under Release configuration.
However it does not seem to work for me...
Here is the relevant part of my regular Web.config file (which holds the Debug connection string for local usage):
<?xml version="1.0"?>
<configuration>
<connectionStrings>
<!-- Debug connection string. Release connection string is in Web.Release.config file -->
<add name="DatabaseEntities" connectionString="A" providerName="System.Data.EntityClient" />
</connectionStrings>
</configuration>
Here is the Web.Release.config file, which according to the examples should replace the 'DatabaseEntities' connection string "A" with "B" if the DLL is under Release mode:
<?xml version="1.0"?>
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<!-- Replace the DatabaseEntities connection string with the Release version (local IP address) -->
<connectionStrings>
<add name="DatabaseEntities"
connectionString="B"
xdt:Transform="Replace" xdt:Locator="Match(name)"/>
</connectionStrings>
</configuration>
(Obviously "A" and "B" are just place-holders for my real connection strings)
When I debug the application (e.g. just press F5) the default Web.config is used and I can access the database. I then change the build configuration to Release via the Configuration Manager. All the projects in the solution are set to Release configuration. Then I Build the solution (just via Build or even via a complete rebuild (e.g. Clean, Rebuild)). I upload the newly built DLLs to the webserver, as well as the Web.config and Web.Release.config files, and when I try to access the database I am unable, it is still trying to access the database via the debug IP address and hence cannot find it...
It seems the Web.Release.config file is completely ignored, or at least the connection string is not being replaced.
What am I doing wrong? Is the transformation syntax wrong? Am I not building the application under Release mode correctly?
Then I Build the solution (just via Build or even via a complete
rebuild (e.g. Clean, Rebuild)). I upload the newly built DLLs to the
webserver, as well as the Web.config and Web.Release.config files
There is your error: Web config transforms won't work for your local environment, if you simply build. You need to publish.
Your deployment process seems weird: You are only copying DLLs, Web.config and web.Release.config. To me it seems, that you copy your source code and not a compiled application. A published WebApplication doesn't contain a web.release.config.
You should publish your project (rightclick on your WebApplication -> Publish) to your local filesystem and copy the files from there, or use another deployment method of your choice.
2 years ago I wrote an article about web.config transforms. It gives you a step-by-step tutorial for VS 2010 (The publish dialog changed in VS 2012): http://www.tomot.de/en-us/article/5/asp.net/how-to-use-web.config-transforms-to-replace-appsettings-and-connectionstrings
Inside your csproj file, you can add an action to execute before every build and perform the web.config transformations:
<Target Name="BeforeBuild">
<TransformXml Source="web.config" Transform="web.$(Configuration).config" Destination="web.config" />
</Target>
You can try the Slow Cheetah plugin:
http://visualstudiogallery.msdn.microsoft.com/69023d00-a4f9-4a34-a6cd-7e854ba318b5
This will let you see the transformations 'live' by giving you an extra context menu option. Right-click and choose Preview Transform to see the transformation without having to do a build. Its also really handy for implementing app.config transformations
I thought transformation is only done when you publish the site/app.
It is not done when building an application. The latter would constantly change the web.config under source control (which would be a real hassle)
If it's only connections strings that are not overwritten during web.config transformation, then this is what I did:
I cleared the "Use this connection string at runtime" check-box in the "Settings" section of "Publish Web" wizard. This setting was overwriting web.config transformation of the connection string.
It's pretty flexible, you should be able to make a few tweaks to apply custom transforms on build (and without having to publish)
We implemented this in our (Windows Service) project, applying transforms on build
You will need to modify your project file and add something similar to below
Here we're telling msbuild to apply transform after finish compiling, but only if condition is true (see https://learn.microsoft.com/en-us/visualstudio/msbuild/msbuild-conditions?view=vs-2017)
Notice we are using an build prop (self defined msbuild prop) "Env", e.g. msbuild ... /p:Env=Prod would result in App.Prod.config
<UsingTask TaskName="TransformXml" AssemblyFile="C:\Some\Path\Microsoft.Web.Publishing.Tasks.dll" />
<Target Name="AfterCompile" Condition="Exists('some condition')">
<!--Generate transformed app config in the intermediate directory-->
<TransformXml Source="App.config" Destination="$(IntermediateOutputPath)$(TargetFileName).config" Transform="App.$(Env).config" />
<!--Force build process to use the transformed configuration file from now on.-->
<ItemGroup>
<AppConfigWithTargetPath Remove="App.config" />
<AppConfigWithTargetPath Include="$(IntermediateOutputPath)$(TargetFileName).config">
<TargetPath>$(TargetFileName).config</TargetPath>
</AppConfigWithTargetPath>
</ItemGroup>
</Target>
In my web.config file, I have a connection string to connect my development database.
<connectionStrings>
<add name="MembershipDB" connectionString="Data Source=DebugSQL;Initial Catalog=PortalAccess;Integrated Security=True;Application" providerName="System.Data.SqlClient"/>
When I publish the web site to my production server, I just change the Data Source name.
When I test it, then I switch it again, is it stupid?
This is quite a common approach and can work well.
Obviously you can run into problems if you get the details wrong while maintaining it by hand this way.
You could also have a look into web.config transformations: This is a way of writing a main web.config file and then writing separate files that change the original depending on the build configuration you run.
Some resources:
Related question on StackOverflow;
Asp.Net tutorial;
MSDN Video for VS 2010.
I am creating a package of an asp.net mvc3 application to distribute it. Means I want to zip it and send it to someone for review. I want that you just start the solution in VS and it runs. So no need for changes in web.config.
I was using sql server with hard-coded DataSource. (COMPUTERNAME\SQLEXPRESS)
I changed it to .\SQLEXPRESS to make it relativ. Better.
Then i detached the db with SSMS, copied the DB to the App_Data folder, added AttachDBFilename=|DataDirectory|MyDatabase.mdf;
And (as found on msdn) Initial Catalog=; "use it but don't set it"->great feature ;)
This is the result:
<connectionStrings>
<add name="DBService" connectionString="Data Source=.\SQLEXPRESS;AttachDBFilename=|DataDirectory|MyDataBaseFile.mdf;Initial Catalog=;Integrated Security=True;MultipleActiveResultSets=True" providerName="System.Data.SqlClient" />
</connectionStrings>
When I start the asp.net Development Server (hit "play") in VS Web Developer 2010 there is a Database error:
Unable to open the physical file ".........mdf". Operating system error 5: "5(Zugriff verweigert)".
Any suggestions how to attach the file to the solution? What about switching to Compact Edition?
Have you tried adding
User Instance=True
?
Data Source=.\SQLEXPRESS;AttachDbFilename="|DataDirectory|MyDataBaseFile.mdf";Integrated Security=True;User Instance=True