I'm not sure exactly how to word this question. Whenever I am publishing an entity framework application from Dev to Test and then to production I've always just changed the connection strings located in the app.config or web.config and then updated my .edmx from those dbs (update from database option). Then did my publish or build and move the files over (from my dev machine).
However, I'm not sure that this is necessary or the correct way of doing it. Is there a better/correct way of doing this?
And if it is a term that I can just lookup, let me know that. I can do the research I'm just not sure how to word it.
In the project(asp.net MVC) it is using Entity Framework 6.
Related
In db projects, when you add a database dac-pac for example as a reference use in a view to reference a third party database, that seems to be valid only for your local copy.
In VS 2015 I can;t seem to find how you add that as a build so that it syncs and compares with the version you store in source control.
If I check out a team project, create a view referencing a third party DB, create a dac-pac for that DB, add it as a database reference, save, build, check in, by default that reference isn't checked in to the server for another developer to check out in the latest version and therefor they will get reference errors.
Does anyone know how to sync these? I can't find an option to do so!
Also, it would be nice to be able to edit the dam things, For example if they are on a different server you must define that. But say the server changes, you can only edit it in your publish profile, however if you do that but someone else doesn't it will flag as a change for them.
You'd better add the .dacpac file to TFS version control. When others check out from other machines, get down the .dacpac file together with that db project.
Make sure that when other check out that file and the db project to their local machine, the relative path between them are same with that in your environment. Actually, in the .sqlproj file of your db project, it has defined the relationship.
For example, I put the .dacpac file under a folder named "DACPAC" and this folder is at the same level of my solution folder.
In the .sqlproj file:
<ArtifactReference Include="..\..\DACPAC\TestDB.dacpac">
<HintPath>..\..\DACPAC\TestDB.dacpac</HintPath>
......
</ArtifactReference>
Note: The "..\" mean go to the uplevel path from where the .sqlproj at. It has 2 "..\", so go 2 uplevels.
I have a database project which uses link servers in several of the views and stored procedures.
According to Microsoft, Visual Studio 2010 database projects do not explicitly support link servers, but you can kind of hack it using References and SQLCMD variables:
http://msdn.microsoft.com/en-us/library/bb386242.aspx
My database (the database itself) has a link server conenction to a Warehouse database. The Warehouse database project is stored in a separate Team Project Collection.
Is there any way to add the Warehouse project as a reference in my project?
The following article explains how to use reference variables in a database project.
http://msdn.microsoft.com/en-us/library/bb386242.aspx
This is necessary when you are referring to a database that is not in the same solution (see the first chart, second row).
In my case, I will probably have separate solutions for each different business environment (internal apps, external apps, warehouse, etc.). Each of these solutions will have several databases. But the databases will need to refer to databases that are not in the same solution (ex., an internal DB might have stored procedures that pull data from an external DB).
In this case, I think the best solution is to refer to the .dbschema file that is generated when the project is built. You can configure a nightly build for each project, and have the build output be copied to a specific shared drive location. You could then point any database project to any other database’s schema by adding a database reference (described in the above article) to the .dbschema ( on the shared drive) for the database.
If you wanted to make it more sophisticated, you could modify the build template to copy the necessary .dbschema files from the build output into each project and check them in.
In the case where the database does not have a project and is not being actively changed, it will be necessary to create a temporary database project for the database so you can build a .dbschema file. The built .dbschema file can then be checked in to the dependent project, and you won’t have to generate it ever again unless it changes.
I’ll do my best at an example…
Problem:
Project ABC depends on the data warehouse, and on project XYZ. Project XYZ is in source control under a different solution, but the Warehouse is not in source control.
Solution:
Create a nightly build for project XYZ
Configure the build output directory to go to a shared drive
Create a custom build template for project ABC that will copy the XYZ.dbschema file in to the ABC project and check it in
In project ABC, right-click on “Database References” and add a reference to XYZ, specifying the XYZ.dbschema file (instead of the XYZ database project, which is outside the solution)
Create the reference variables to the XYZ project (not sure this is necessary…)
Replace references to XYZ in stored procs & views with the reference variables you created in the previous step (not sure this is necessary…)
Now the references in ABC to XYZ should resolve.
Create a new database project (this can be a temporary, throw-away project)
Have it pull the definition from the Warehouse (right click the project and select “Import from database”)
Build the project
Copy the Warehouse.dbschema file from the build output into the ABC project
In project ABC, right-click on “Database References” and add a reference to the Warehouse.dbschema file
Create reference variables for the Warehouse
Replace references to the Warehouse with the reference variables
Now the references in ABC to the Warehouse should resolve.
I don’t know if it will work just like that, but that is the theory. Hope it helps…
I'm working on an ASP.NET MVC website. Each time I do important modifications, I copy/paste the entire folder of my solution and rename it something like MySolution v1.1, next time MySolution v1.2, ... In that way, I can always step back easily and keep versions. But I always have problems with the database.
Example:
I work on MySolution v1.1 with the database in the App_Data named MyDB1.mdf
I copy/paste previous version in MySolution v1.2 folder
I cannot run successfully this newly created solution because Visual Studio will try to recreate the database named MyDB1.mdf but this one already exist (in the previous folder).
I had to change database name in the connectionstring of the web.config file and clean the App_Data folder.
This is not a good way of doing things. Furthermore, I lost my data in my DB because I delete it each time.
Does someone can give me advices for versioning my different solutions?
I hope I was clear.
Thanks in advance.
I'd suggest using a revision control system, such as Subversion or Mercurial (using TortoiseHG). This way, you can just revert to a previous version of your code if you don't like the changes you made.
I encourage you to get familar with source control. This is really important and every developer should know about it.
Here some source control systems:
Subversion
GIT
Mercurial
There are other version control systems as well. Personally I prefer Mercurial.
Hope this helps!
Use version control.
If you are working in VS you can use TFS. It has good integration into it and easy to learn (free TFS for open source projects can be found on www.codeplex.com).
Also you can use GIT (www.github.com), TortoiseSVN, etc.
Also you can do versioning for Database. In this case you can store database schema in Database project or create change scripts for database.
I have seen a number of demos from 'respectable' individuals demonstrating the merits of the code first feature for Entity Framework. All of which looks like mouth watering toys!! but one thing strikes me...
Other than in development when would a code first scenario benefit my project?
Having the framework build the database for me seems awesome in a development and testing (portability!!!!) stage of the project but when I update the live project I would not want any of this to occur.
Knowing when the framework is about to overwrite my database and inserting my static data back in seems like a reasonable idea (for test scenarios) but all the demos I have seem put the code to construct this in the EF assembly.
EF Migrations is going to make this clear??? Maybe. Anyone have views on why I should be using this code first?
In my opinion automatic database generation is only for development and testing. Once you move your application to a production environment you should make sure that this feature is turned off. This is especially important once you decide to deploy new version of your application.
EF Migration will perhaps change it by I'm sceptic. I would never let some automatic black box touching my production data. We already had very bad experience with VS Database tools so we never let them working with real data directly - we only let them generate script for us, we precisely test these script and manually execute these scripts on the production. Sometimes it even requires adding some additional migration scripts with temporary tables. That is exactly the approach which should be in my opinion used with EF as well. Let code first crate a new database in your dev environment, use a tool to create difference script for you against the old database, test it and deploy it.
But most importantly: Any upgrade or change on production database should start by backup so if tool fails you can always go back.
Choosing code first / database first / model first is based on the way how you like to develop application and on other requirements you have.
So I have a VS 2010 solution containing one ASP.NET MVC 3 project and one SpecFlow project (with NUnit as test runner) to test the former. When testing under SpecFlow (by running the SpecFlow project), I'd like to change a parameter in the MVC application's ConfigurationManager.AppSettings dictionary, to make it connect to a test database. This change does not seem to affect the running app however, so I guess the test and the app do not share state.
How can I share this application setting between the MVC app project and the SpecFlow project, so they use the same database?
Edit:
I found that the problem wasn't really one of sharing settings between projects (MVC and SpecFlow), but rather between two processes. The reason is that I test MVC via WatiN, which means that the development server, running in a process of its own, is being exercised by the tests. As such the premise of my original question was wrong from the onset, and I consider Jason's answer valid given the original premise.
In your test project (SpecFlow) create a new app.config (unless it's already there) and add the appSettings section to that, with your test database connection string. IIRC the website will hopefully pick up the connection string from the appSettings of the test project, rather then the website.