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.
Related
Sorry for the noob question. Someone has insisted me that it is possible to connect the .bak file to the asp.net website by just using connection string in the web.config only. However, I am in the midst of confusion because it doesn't make any sense to me because the .bak file is the backup file for the SQL Server.
My real question is, is it possible to connect it without dealing with SQL Server? What are the alternatives and suggestion you have?
Here's the example of web.config file he shown to me.....
<add name="accountConnection"
connectionString="Data Source=\data\websiteXl.bak; Initial Catalog=websiteXl;Integrated Security=True"
providerName="System.Data.SqlClient"/>
I have tried alternatives like using .mdf too....
<add name="accountConnection"
connectionString="Data Source=\data\websiteXl.mdf; Initial Catalog=websiteXl;Integrated Security=True"
providerName="System.Data.SqlClient"/>
This is utter crap - you cannot just connect to a .bak file, you're right (and that "someone" is plain wrong).
You will need to restore that .bak file onto a SQL Server instance, and after that's done, THEN you can use that database
No, that isn't possible. The backup file generated by SQL Server (usually with a .BAK file extension) is a compressed backup file that's not directly usable, generally.
The only thing you can really do with it is to restore the database, or make a copy of that "snapshot" of the database on another server, or the like.
There are some tools (like Red-Gate's SQL Compare and SQL Data Compare) which can show you the differences between a backup file and a live database, or between two backup files. But, that wouldn't help you connect to it through an ASP.NET page.
I have a site that's running off windows azure and I have hooked up the database via a linked resource and it looks like the site should be using the database. I've also included the proper connection string in my web.config file.
When I run the website locally and use the azure database's connection string for my default connection, everything works and I've seen that updating data from my local machine is reflected in the remote database.
Whenever I try to access any page that makes database hits (ie, logging in or looking at the basic index (from scaffolded out views)), I get a 500 error. I tried turning on custom errors but the 500 error is all I get. I tried to debug it from my local machine but that didn't help at all since everything worked properly when running the site locally and connecting with the azure database.
I have also pulled down the web.config files and the web.configs on both sides are identical.
I figure that this has to do with a configuration issue, but I'm not sure what.
Is there maybe something I'd have to do with asp.net mvc 5 to make it work with windows azure? It looks like the .net framework is properly set on azure to .net 4.5. I'm guessing it has something to do with the fact that Azure just doesn't know it should be using the database supplied in the web.config.
Here are the web.config connection strings:
<add name="DefaultConnection" connectionString="Data Source=####.database.windows.net,1433;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
<add name="DefaultConnectionDeploy" connectionString="Data Source=####.database.windows.net;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
<add name="DefaultConnection_DatabasePublish" connectionString="Data Source=####.database.windows.net,1433;Initial Catalog=####_db;Persist Security Info=True;User ID=####;Password=####" providerName="System.Data.SqlClient" />
Windows Azure makes use of transforms to manage connection strings. The connection strings are merged in at runtime, and can be controlled from the configure tab on the Web Site management page. whenever you set up an Azure Database as a linked resource, it automatically configures the Azure Database server with firewall rules to allow connection from the web server, and adds a connection string. By using this connection string, naming it the same as the string used in development, it is not necessary to modify any code prior to deployment. If you don't set the Azure Database up as a linked resource, it is necessary to modify the firewall rules by hand, which doesn't play nicely with the scalability of Azure Websites, so it's not recommended.
As per Andrew-counts' suggestion, I went and checked out my EF migrations (after pulling down the Azure web.config file using the "Replace web.config from server" option so that I had the exact copy that the server is using. I then enabled custom errors. It turns out that the pages were failing to load because of an error that stated that the table dbo.AspNetRoles already exists.
It appeared as though it was trying to run the EF migrations despite the fact that the tables already existed. To remedy this, I decided to go and wipe out my current database (I had just setup the database today so no harm doing that) and then, from the package console in visual studio, ran the Update-Database script before deploying anything to the server. When I did that, it correctly added the records inside of the dbo.__MigrationHistory table. I then checked in my changes so that the visualstudio.com build I have connected to my solution would build and deploy to Azure. The problem persisted, but what I realized was that I need to disable the automatic build + deploy that I was using and instead use the right click + publish, since doing it from the visual studio build wasn't connecting to the azure database properly (it wasn't transforming the web.config). When I used the publish from within visual studio, the site worked like a charm.
Thank you for all your help
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>
I just upgraded to Visual Studio 2010 and MVC 2.0 and I noticed the Web.config has two additional files attached to it? Are these files used to specify debug and release specific settings, so you don't clutter up the main Web.config?
Does it even make sense to place a connection string in the root Web.config file if I have a local and remote one in the debug and release Web.configs respectively?
Thanks!
It's the new Web.config transformation feature of Visual Studio 2010. More information here.
Edit:
Are these files used to specify debug and release specific settings, so you don't clutter up the main web.config?
It isn't limited to three files, you could (in theory) have as many files as you have environments. The "top level" Web.config provides a template of your web config. The files under it provide replacement values specific to that environment (like if you have different connection strings for local/stage/test/whatever).
Does it even make sense to place a connection string in the root web.config file if I have have a local and remote one in the debug and release web.configs respectively.
It would only make sense if it wasn't going to change between environments. Sounds like in your case it does so, in your case no, it would not make sense to leave it in the Web.config.
These are Web.config transformations files. From ASP.NET Web Deployment using Visual Studio: Web.config File Transformations:
There are two ways to automate the process of changing Web.config file settings: Web.config transformations and Web Deploy parameters. A Web.config transformation file contains XML markup that specifies how to change the Web.config file when it is deployed.
You can specify
different changes for specific build configurations and for specific
publish profiles. The default build configurations are Debug and
Release, and you can create custom build configurations. A publish
profile typically corresponds to a destination environment.
In case anyone is interested, here is something I wrote up to have a dynamic connection string per environment. I wanted to deploy the code to any environment (Dev, Test, Pre-Prod, Prod...) without having to worry about changing connection strings. I couldn't really find a good way to do this with Asp.Net MVC 4, so I came up with my own way to rely on a properties file per environment.
There may be a better solution, I come from a Wicket/Java background and recently started developing with MVC 4 so, it's possible a better solution exists. But here is a link to my question and answer for a dynamic connection string:
Asp.net MVC 4 dynamic connection string
That was something long needed in VS. Unfortunately there seems to be a problem with the implementation. For example consider this scenario (VS.2010 Ultimate, all SP):
Web.Config
No connectionStrings section
Full Membership User/Role/etc. Provider configuration using connectionStringName="test"
Web.Release.Config
No membership configuration (already specified in main web.config)
connectionStrings section including the CS named "test"
Web.Debug.Config
No membership configuration (already specified in main web.config)
connectionStrings section including the CS named "test"
When executing the application gives the following error:
The connection name 'test' was not found in the applications configuration or the connection string is empty.
In other words, because the connection string elements are in the Release/Debug designer files and used by configuration elements in the main (Web.config) file, it is unable to resolve it.
My environment is Visual Studio 2005. My specific problem is that I want to define TRACE.
I have a Web Site Project that send trace messages when run out of the ASP.NET Development Server thanks to defining it in the system.codedom element of the web.config.
When I deploy to IIS, I do so via a web deployment project. So the site is precompiled. Naturally, these entries serve no purpose on a compiled website.
My question is how do I define TRACE in the web deployment project?
The visual Studio IDE does not allow you to set compile time constants in web deployment projects as far as I can tell. However, since a .wdproj file is just an msbuild file, you can edit it with a text editor. You need to add a element to the sections as illustrated in the screen shot in the provided link.
I cannot change the link to an image since new users apparently can't add images:
Annotated screenshot of .wdproj in a text editor http://img140.imageshack.us/img140/1719/deploymentproject.png
There is no equivalent to #defines in C#. That said, it sounds like you want to use conditional tracing, which is easily accomplished. If you have diagnostic code throughout your project but want to define it, use the built in trace functionality, for example
System.Diagnostics.Trace.WriteLine("Some debug output");
Then, in your webconfig, you can configure it on/off using
<configuration>
<system.web>
<trace enabled="true" requestLimit="40" localOnly="false"/>
</system.web>
</configuration>
More info here