For my current project i would prefer to update my database to the correct version on publish instead of first run via the App_Start.
It seems that there is support for manual upgrades via a commandline tool 'migrate.exe' which is supplied together with Entity Framework (5.0 rc2). But i can not find any information about how other people have combined this tool together with msdeploy to upgrade the database on publish instead of first run.
I have found the following page which explains how to use the migrate.exe tool:
http://blog.overridethis.com/blog/post/2012/03/13/Automating-EF-43x-Data-Migrations-in-your-Build.aspx
But this forces me to somehow 'know' the connectionstring information.
My optimal solution would be something like:
connectionstring is configured in setParameters.xml file for
replacement on publish
on publish after publish of codebase
migrate.exe gets called with correct connectionstring
It seems that what i search for is an 'entity framework MSDeploy provider' (see: http://blogs.msdn.com/b/adonet/archive/2012/01/12/ef-4-3-beta-1-released.aspx) but it seems that they abandoned that option some time ago
You have two options:
Configure Visual Studio Databases option in the Publish Profile; or
Configure your project properties on Package/Publish SQL Tab.
I didn't use any of them yet but I was researching because I'll have the exactly same scenario.
Related
I have an Azure website configured to deploy from Visual Studio Online (hosted TFS). I'm evaluating the move from Database First model to Code First from Existing Database model.
Currently, As I check-in code to Visual Studio Online, it is deployed to Azure website. How to configure this process to run EF Migrations on the remote (live or test) Azure SQL database when I check-in code to Visual Studio Online.
AFAIK, you need to use the publish profile option to achieve this.
You have to download the publish profile settings file for the website, Import the file in Visual Studio, configure the Execute Code First migrations option and then specify the profile file path in Build Definition used for Continuous deployment.
You can check below post for reference.
http://blogs.msdn.com/b/webdev/archive/2014/04/09/ef-code-first-migrations-deployment-to-an-azure-cloud-service.aspx
I know it is a old post, but I could't find a good answer, so after figure out how to solve it I'm sharing a solution. I work in a project with DDD and N-tiers level. So, it means that the EF isn't in the same project as WebApi, therefore has no option to run migration during the publish wizard. To solve it I have ran update-database directly from package manager console.
Steps:
Acquire the ADO connection string (https://azure.microsoft.com/en-us/documentation/articles/sql-database-connectivity-issues/#connections-to-azure-sql-database)
From package manager console run: Update-database -StartUpProjectName NAMEPROJECTWITHEF -ConnectionString "connection string obtained from item one" -ConnectionProviderName "System.Data.SqlClient"
That's all!
Best Regards,
thiago
I have some questions around the best mechanism to deploy MVC web applications to different environments. Previously I used setup projects (.msi's) but as these have been discontinued in VS2012 I am looking to move to an alternative.
Let me explain my current setup. I currently have a CI setup using TFSBuild 2010 with Team Foundation Server for source control.
A number of developers work on their local machines and check in to the TFS Server. We regularly deploy to a single server dev environment and a load balanced qa environment with 2 servers. Our current process includes installing an msi which carries out some of the following custom actions:
brings current app offline with the app_offline.htm file
run in database scripts (from database project in the solution)
modifies web.config (different for each web server of qa)
labels the code
warmup each deployed file via http request
etc
This is the current process. Now I would like to make some changes. Firstly, I need alternative to msi's. From som research I believe that web deploy via IIS and using MsDeploy is the best alternative. I can use web config transforms for web config modifications. Is this correct and if so, could I get an outline of what I need to do?
Secondly I want to set up continuous delivery via TFSBuild, I have no idea how this may be achieved, would it be possible to get an outline of how it can be integrated in to my current setup? Rather than check in driven, I would like it to be user driven following check in. Also, would it be possible for this to also run in database scripts from a database project in the solution.
Finally, there is also a production environment, but I would like to manually deploy this - can my process also produce an artifact that I can manually install?
Vishal Joshi has some information on his blog that is reasonably good, http://vishaljoshi.blogspot.com/2010/11/team-build-web-deployment-web-deploy-vs.html. It does have the downside that your deployment password is include in the properties you pass to msbuild.
Syed Hashimi has also posted some information on this in another questions Team Build: Publish locally using MSDeploy.
I'm going to deploy an application click once and wondered what the best technique for dealing with the database, since the click once install sqlserver to me I was wondering how I determine the sqlserver installed so that when the application is first run, see it and create the sqlserver database.
I would not use the windows install to distribute this application because it will have multiple versions of update, and would be easier with clickonce.
Which flavor of SQLServer are you using? Here's some helpful information.
If it is SQLServer Express, you need to add the database to your project and set the build action to 'content' and set 'copy to output directory' to 'copy if newer'. This will ensure the database is included in the deployment.
Next, go into the prerequisites dialog and select SQLServer Express. When the user runs the setup.exe, it will check and see if it is installed, and if not, will install it.
If you want the newest version of SQLServer Express, you can find how to create a bootstrapper package here -- Microsoft doesn't provide one, but this article provides the XML you need and provides links to the SQLServer Express downloads.
If you are using SQLCE, you need to attach the database (*.sdf) to your project and set the properties as noted above. However, you do not need to publish this as a prerequisite, you can just include the dll's in your project as noted here.
When your publish a new version, if the database has changed, ClickOnce will put the new database in the DataDirectory and put the old one in the \pre subfolder of the DataDirectory, and you have to write code to handle that. This sounds appealing, but I think it's dangerous. If you even so much as open your database to look at the structure, it will change the date/time stamp, and ClickOnce will think it's new and publish it, and you will get calls from your customer about their data missing, unless you handle this.
So I usually recommend you copy the database to LocalApplicationData when the user first installs your application, and handle any updates to the structure programmatically after that. There is an article about how to do that here.
I have a Azure project (Azure 1.3) in VS2010. There are 2 webroles, one web page project and one WCF project. In debug mode I want the web project to use a web.config for DEV enviroment, and when publishing the web.config for PROD must be used.
What is the best way to do this ?
Currently I am facing issues when using a Web.Debug.config with transform XSLT. It doesn't seem to work in Azure....
Solve your problem a different way. Think about the web.config always being static and never changing when working with Azure. What does change is your ServiceConfiguration.cscfg.
What we have done is created our own configuration provider that first checks the ServiceConfiguration.cscfg and then falls back to the web.config if the setting/connection string is't there. This allows us to run servers in IIS/WCF directly during development and then to have different settings when deployed to Azure. There are some circumstances where you have to use web.config (yes, I'm referring to WCF here) and in those cases you have to write code and create convention instead of storing everything in web.config. I have a blog post where I show an example of how I did this when dealing with WIF (Windows Identity Foundation) and Azure.
I agree with Mose, excellent question!
Visual Studio 2010 includes a solution for this type of problem, web.config transforms. If you look at your web role you'll notice it includes Web.Debug.config and Web.Release.config along with the traditional web.config. These files are used to transform the web.config during deployment.
The canonical example is "I need different database connection strings for development and release" but it also fits your situation.
There is an excellent blog post from the Visual Web Developer Team that explains how to use this feature (don't bother with the MSDN docs, I know how it works and still don't understand the docs). Check out http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
I like this question !
For worker roles, I solved this problem by detecting the environment at runtime and launching my 'application' in a new AppDomain with a custom configuration :
bot.cloud.config
bot.dev.config
bot.win.config
This is incredibly efficient !
I'd like to do the same with web projects, because using the Azure specific configuration is a lot of trouble :
Both config are not in the same place, which is time-consuming when debugging
You have to learn a new way of writing something that sould be standard
Sometime you'll wonder if the app falled back on web.config because of a stupid syntax error
I'm still searching the right way to do that, like in this post
Another possible solution is to have two CloudService projects, each one with specific ServiceConfiguration.cscfg(dev/prod). Develop using the Dev, but deploy the Prod.
Currently I am facing issues when using a Web.Debug.config with
transform XSLT. It doesn't seem to work in Azure....
It depends on whether you want to make it work on your local machine or inside continuous integration.
For the local machine I tried to answer here: https://stackoverflow.com/a/9393533/182371
For the continuous integration it's even easier. When you build from the command line specifying the Configuration property value your configs WILL be transformed (no matter what it does when you build inside VS). So properly specifying build configurations for both cloud and web project will give you the correct output depending on build parameters.
With VisualStudio Publish, CruiseControl.NET, MSBuild, aspnet_compiler.exe, and Web Deployment Projects out there, how would one know which tool to use to ultimately get a .NET 2.0 web application into a testing/production environment?
With .NET 1.1, I simply copied all files over to the server's directory and set it to a configured virtual directory in IIS. Unless I am really missing something, it seemed to work just fine. Now I'm reading about how important it is to put some good thought into 2.0 deployment and the the more I read, the more I get confused.
Please breakdown how to choose which tool to use, and why you would use that tool. If more than one tool is needed, please identify how they relate to this process.
CC.NET is for Continuous Integration it can build your setup projects as artifacts, but that is not it's main purpose. MSBuild is the Microsoft build system -- again, not related to deployment. aspnet_complier compiles your web sties, which may make deployment easier, but is not in itself deployment.
Web deployment projects is what you should be looking at. Here's a decent little post that goes over some of the options for deployment and a reference from MSDN. There are also commercial products.
In most cases, you can right-click on project in VS.NET and choose "Publish". This will give you a few options for deploying via FTP or file path.
Publish Web http://img26.imageshack.us/img26/1261/screencfl.png
What we do it publish to an SVN repository, then run SVN UPDATE on the machines it needs to go to...
I use TeamCity, which implements
Rebuilding solution with
devenv.exe in command line
Changing settings in web.config
(connection strings and debug mode)
with sed.exe
Precompiling WebSite
with the aspnet_compiler in command
line.
Copying solution to FTP
(with internal tool)