Recently we started working with Database project in Visual Studio 2010. I have added a reasonably large database to the solution and imported all objects. All warnings have been eliminated so it builds fine.
The one thing that really annoys me is that when you open the solution, the database project will start to load the database schema which takes some time (minutes) and uses a lot of resources. Practically I am not able to start working the moment the solution was loaded.
Is there any way to disable or change that behavior other than removing the database project from the solution or other hardware?
Answering my own question: unload the project.
This way it will (locally) not load the next time you open the solution.
If you need to work on the database project, just load it, work on it and unload it again.
Related
We have two software projects that both communicate with a single database. Right now SQL updates are all done on the database and it's relying on developers to make sure to update both sets of projects independently to use the latest database model. Making these matters worse both projects are in separate solutions in separate source control repositories.
While I acknowledge this is a terrible situation to be in, I inherited this situation, and while my long term goal is to consolidate and share the (lots) of duplicated logic between them in one common project shared among both sets of application for various reasons it is not feasible to jump right into that right now due to critical deadlines coming up and the need to combine them iteratively and schedule it with other developers to not disrupt work too much.
Keeping that in mind, I really want to use SSDT to at least start bringing the database structure under source control and make it easier to manage, as there are quite a few database changes that I'm about to do.
The problem with SSDT in this scenario is that you can only import from database once. After that the option is greyed out and unavailable, which is apparently a design decision of SSDT, since it's explicitly listed in the MSDN documentation.
Is there any easy way to update my SSDT project without nuking the current project and recreating it each time someone makes a change to the database structure?
Firstly your right, it is a horrible situation so work on improving it in the long term!
There are two things you can do, firstly you could use SSMS "Generate Scripts" to export all the objects and then use the import in SSDT to import from the scripts - this isn't greyed out.
The second thing you can do is manually bring the changes in using the schema compare in SSDT, you can set the database as the source and project as the destination and choose what you drop, update and import.
Ed
its bit delay in answer. I am using VS2017 Database project in which I have achieved this task by comparing a local database with database project once the comparison is over you can update the database by update button
Step 1 right click on the database project and click on schema compare item.
Step 2 select target -> select database connection option
Step 3 change source and target
Review Screenshots for more detail
I am going with compare solution :
Choose schema compare and make your database as a source and database project as a target then compare and update
see the this answer
Make a new temp Database project (outside of TFS) and import all the objects.
Checkout the Database project (inside TFS) and copy and paste all the folders (excluding BIN, OBJ folders) from the new temp Database Project into the Database Project (in TFS) and check in. This was way you get the latest DB object into TFS without duplicating.
If you expect new files in the copy/paste operation, then the new files should be included in the DB Project.
Delete the temp Database project folder.
You will need to do the process whenever you want to update all DB Objects into TFS.
This is a workaround which worked for me for this file duplicating issue.
Currently I'm using Visual Studio 2012 RC and SQL Server 2012 RTM.
I'd like to know how to re-deploy/re-create a test database for each test run.
Keep in mind I've a SQL Server database project for the database using Visual Studio 2012's template.
Actually I'm not very sure about an idea I got in my mind, but .testsettings file has Setup and cleanup scripts. Is this the way to go? For example, a PowerShell script reading the database project generated script and executing it against the database?
I guess there're better ways of doing that and it should be an out-of-the-box solution but I ignore it and Google doesn't help me in finding the right solution.
As mentioned you'll probably want to use the VS 2012 .Local.testsettings > Setup and Cleanup scripts to create / tear down you SQL Server database.
For the script you may want to use powershell with a .dacpac (rather than just a T-SQL script), since you are using a SSDT project. Here's a link to some example code - in particular you may want to take a look at the 'Deploy-Dac' command.
If you are unfamiliar with .dacpacs as the (build) output of SSDT-created database projects, take a look at this reference link.
Edit: Although this doesn't answer the question in a plain SQL Server way, an easy Entity Framework approach would be the following: I found that I could create and destroy my database every time correctly by using the DbContext.Database.CreateIfNotExists() and DbContext.Database.Delete() methods in my setup and cleanup phases of my tests.
The fastest solution, while a bit of a hack, is really straightforward. You can set the DB Projects properties under the debugging tab to "always re-created DB". Then test in two clicks, do a debug/build, then run all tests. You should get a freshly built DB on localDB for you tests to be ran against. You can also change the target for the debugging DB (again the DB projects properties) to whatever you want, so you can deploy to a .dacpac, or to an existing SQL DB or wherever. It means testing in two steps, and if your build is long, it may be annoying, but it works. Otherwise, I believe scripting is your only option.
In the last year I've worked on two relatively large .NET projects and both of them have ended up with project/code generation strangeness that I just haven't figured out how to fix..
The first project generates some bad code for forms that causes the VB.Net build to fail. I actually had to make a search/replace macro that fixes the 5 problems by adding a Global. to the beginning of a few references.
I chalked that up to a random act of unkindness against me and went on my way since the macro takes about 2 seconds to run...
So now 6 months later and new project is cranking along and I get a similar-ish problem. I have a bunch of form controls that store state in a settings file using the built in capabilities of .Net. I had about 20 controls that were configured automatically this way. Works great until today when for reasons I don't understand in the designer.vb file gets corrupted. At least one other person on the planet has had this problem here:
http://social.msdn.microsoft.com/Forums/en-US/winformsdesigner/thread/9bd20b56-7264-4a1f-a379-ad66b372ddd3
but the proposed solution didn't change the behavior.
So now I've had two projects (larger ones) that have project file issues that I can't resolve (I've had several smaller projects that are just fine).
What tools are available to fix projects, migrate projects, lint projects ... anything to recover projects to a reasonable state? Any successful recovery procedures beyond a roll-back/merge?
i had a corrupted reference issue linked to my use of mercurial and VS getting lost in file save time... if this may help...
If you open it in notepad and its corrupted - then its probably corrupted and the only way to restore it would be to go to a backup.
--> go to backup
-->click your project name
-->and then find your fire thats are corrupt
Our issue is as follows:
solution takes a while to start up when running
after hitting run and while monitoring the Output window, constant work done is loading project related files from .net temp dir
this really takes a while
this is a Web Forms app with quite a large set of UI controls/pages and about 250 DLL/component dependencies
references are added as DLL refs and not proj refs
Given the information above, what would be some of the suggestions to speed up solution startup at run times?
Frankly, there may not be a whole lot you can do. But be sure to disable antivirus scanning of the project, as scanning each file as it loads will slow the machine to a crawl.
There are a few other tips floating around, but I'm hoping performance will be improved via an update of some sort.
Lots of links and things to try are here:
http://www.experts-exchange.com/blogs/TheLearnedOne/B_4684-Visual-Studio-NET-2010-Performance.html
I have recently been through the pain of converting an legacy WebSite project to a (C#)Web Application Project. During this time I also migrated the code from VSS control to Subversion on a dev server.
When debugging the application under VS2008 the project can literally take 4/5 minutes to completely load up. The majority of this time the Output Window states that it is loading symbols from Temp ASP.NET directory.
Figuring this may be an issue that it is under SVN control, I exported the project and began debugging without source control and this resolved the issue.
Can anyone suggest why this could be happening, ie. why under source control is it taking such a long time to debug?
Symbol loading shouldn't have anything to do with .svn. If moving your project solved the problem, I'd guess it's something to do with the difference between your actual copy and the exported one. Particularly, I'd say it would be to do with a file unlikely to be committed, like a ".user" file. The ".user" file probably has a lot of extra junk that VS is trying to load, and moving it means they got reset.
Check for any files missing (after a clean export...they'll have been re-created after you open the solution 1x) and you'll probably find the culprit.
You could try the TortoiseSVN client
The more plugins (Resharper etc) you have for VS the slower things tend to get.