I have a database project in Visual Studio 2012. When selecting "Deploy MyDBProj" on the Build menu nothing happens.
When I hit F5 to debug however, the database project is deployed, using the settings in the debug section of the database project properties. This is enabled in by checking the "deploy" checkbox in the solution's configuration manager.
I would like to be able to do a deploy, without starting a debug session. How do I do that?
Note: This is not publishing, which is something else. I want to know how to manually initiate the deploy that is part of the build process. Since the deploy is already done automatically it should be possible to initiate it manually too.
I got an answer from Microsoft at MS Connect:
There was a bug in the version of SSDT that shipped in Visual Studio
2012 in wuich the Deploy menu command appears but is a no-op. This has
since been fixed and is available in the latest version of SSDT:
http://msdn.microsoft.com/en-us/data/hh297027
The only way I can think of doing it (though I haven't tested it) would be to use the command line to do it as outlined at http://msdn.microsoft.com/en-us/library/dd193258(v=vs.100).aspx.
Though once you have your manifest, you can run:
VSDBCMD /a:Deploy /dd:+ /manifest:manifestFileName.dbmanifest
from a command line to deploy your database.
The manifest will contain your target database name, connection string, and so on but you can also specify those as part of the command line instead.
Related
We're just in the process of transitioning from VS2013&15/TFS2013 to VS2017/TFS2017 (on-site TFS, not VSTS) and the first test solution is a dotNet Core 1.1 based one (a multi-project web service).
The solution builds fine on the original developer's box and I've got it out of TFS and it builds fine on mine too. In keeping with our previous methodology the contents of the packages folder are checked in with the projects as this makes the packages locally available on the build box (no internet).
Building the solution on the build server is a different story, however, as I get multiple errors of the form...
..\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
This whole project.assets.json not found issue seems to be causing headaches all over. In my case the issue is that I'm trying to resolve it on our TFS 2017 Build Server, which does not and never will have internet access ('cos it's a server!).
All the solutions I've seen thus far seem to suggest running the Nuget Restore command but that can't work since the server cannot get to nuget.
This is nothing fancy yet, just a simple TFS 2017 Build definition with a Get sources and a Build solution step. I can't understand how something so simple has become so difficult.
Changing the Nuget Package Restore options makes no difference.
Since the project.assets.json files are generated on the fly in the obj folder, I can't even check them in to reuse. Can anyone please suggest a workaround, at the moment the test project is dead in the water.
Edit: trying the same process with a 4.6.1 web project created with VS2015 had similar results of unresolved references (e.g. System.Web) but didn't raise the same error, probably due to being an older, non-Core project.
According to I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
The issue seems not related to TFS build side since it also not work with local build through VS in the build agent machine.
Since this is a dotnet project. So, you could try to use “dotnet restore” and not “nuget restore”. Try using the dotnet core template (which uses dotnet restore).
If you are using authenticated nuget feeds, then you can use nuget restore but you also need to use nuget installer task. See https://github.com/Microsoft/vsts-tasks/issues/3762 for a discussion on that.
The Nuget version should be higher than 4.0.
Without dotnet restore and Nuget restore and only use get source/Visual Studio Build will not be able to build the dotnet core project. If your server do not have internet access, as a workaround you should use Local feeds.
Recently, I have been facing this issue where my TFS(2015 update 3) msbuild runs with old code even after checking in changes and saving changes locally in visual studio 2015 enterprise edition. I use build to run Automated UI test by running my machine as test agent.
I can see an agent workspace other than my workspace(don't know if anything to do with it).
Can anyone guide me to correct this issue, or anyway to move forward without facing this issue again?
Please try below items to narrow down the issue:
Check the source code via web portal, verify that the new changes are
really checked in.
Check the definition setting, try to set "Clean" to "True" in
Repository tab.
Also enable the "Clean" option in MSBuild step.
Try to create a new definition with the same settings, then try it
again.
Clean the caches for your TFS Application Tier and agent machine,
then try it again.
Reboot the TFS and agent machine
UPDATE:
Below screenshot for your reference, also make sure you mapped the source correctly. You can also try to delete workspace and entire source folder directly from your agent machine, eg C:\Agent\_work\2\s (You can get the info from build log)
I am so close yet so far from getting my Visual Studio (MVC) application released through TFS & Release Management. I am using Version 2013 and have my build definition setup as follows:
As you can see it is using the TfvcTemplate.12.xaml as its template, and as such I cannot see the options for Release as I have been finding in all other examples online - eg:
I have gone into Release Management and setup my Release Template to reference this build definition and selected 'Can Trigger a Release from a Build'... but I have nothing happen in RM when I Build in Visual Studio.
What I have also found is that because the application I am building is MVC with Windows Authentication - every time I run a manual release, the Web Site gets rebuilt (as per my release template), but the website is always rebuilt with Windows Authentication Disabled... Which is a pain as I keep having to go into IIS after every release to enable Windows Authentication.
So, my questions are...
1) What am I doing wrong with my version of the Build Definition setup that it will not prompt a release?
2) Do I have to Remove and Create my website on the Release Template... and if so...
3) How do I get around the fact I always have to revisit IIS to enable Windows Authentication after each release?
Thanks!
You need to switch your build template to ReleaseTfvcTemplate.12.xaml.
You can find that file in the folder:
Program Files (x86)\ Microsoft Visual Studio 12.0\ReleaseManagement\bin
You need to check that into your TFS repo, then switch your build definition over to use it.https://msdn.microsoft.com/library/ms181355(v=vs.120).aspx#add_template
How do I create a TFS Build which automatically runs a Release (deployment) from Microsoft's Release Management for Visual Studio 2013?
In order to start a release off from your TFS Build, you need to change the Build Definition. Luckily when you install Release Management it creates a Build Template for you to use with an example. In may instances this will be enough to get you going.
Release Management Build Process Template
Release Management Build Process Templates are not installed in TFS by default, so it won’t appear as an available build process template until you add it.
Find the Template in your server install in : C:\Program Files (x86)\ Microsoft Visual Studio 12.0\ReleaseManagement\bin\
TFS 2010 : ReleaseDefaultTemplate.xaml
TFS 2012 : ReleaseDefaultTemplate.11.1.xaml
TFS 2013 : ReleaseTfvcTemplate.12.xaml (or ReleaseGitTemplate.12.xaml if using GIT)
To add the release management build process template, you will need to check it in to your TFS source control in the BuildProcessTemplate folder in your project. Then add the build process file when editing (or adding) a Build Definition. Once the release management template has been added to the list of build templates, you can start using it.
Please ensure you use the above templates from the Release Management Server and not the client directory as I did initially. You will get rather odd errors during your build if so, such as:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets (3883): Web deployment task failed. (Unknown ProviderOption:DefiningProjectFullPath. Known ProviderOptions are:skipInvalid.)
Package Pickup \ Path to package.
When you set up your components, Release Management needs to know where to pick up your installation files to do something with them. When you created your Release Template it should be connected to a specific build by selecting the build definition that will initiate it (also tick "can trigger a release from a build?"). When you add the components to install as part of your release you specify their Source. "Builds with application" should be selected. The bit that got me was the big empty box next to the Build Drop location which is a mandatory field. My initial reaction was to fill it with the name of the msi file I was trying to deploy. That makes sense right? wrong. If I queued a build from Visual Studio I kept getting the following message.
Package location '\\blah\blah\Build Name\Build Name_20140707.3\A.Product.To.Install.msi' does not exists or Deployer user does not have access.
The file did exist in the location and the user the deployment agent was using did have access to the drop directory. I had also confirmed it was able to access it using ProcMon. After sleeping on it I decided to hover my mouse over the input box and a nice tooltip pops up saying:
The package path relative to the build drop location is required for
component bound to a Release Template. If the package is directly at
the root of the build drop location, you need to enter the '\'
character.
So, after my eureka moment, I deleted the msi file name and replaced it with a "\" and queued the next build. It worked. In retrospect I think they should remove the mandatory requirement for something to be entered to replace the need to enter a "\". It's a little hidden and not intuitive.
See MSDN Article here for more info
For Modified Build Process Templates
I recently had a PC failure and reinstalled the Windows OS and all my development software. After re-installation, my Visual Studio 2012 Database Projects seems to work differently and I cannot figure it out. My database projects no longer "automatically deploys" to the LocalDB when I press F5 or CTRL+F5. I am using VS2012 Professional version with the default installation settings.
On my old installation, if I changed a column name in the project and pressed F5, the table in LocalDB would be updated immediately without any sort of publishing actions or anything. The Visual Studio output window would also indicate that changes are being applied. This "automatic deployment" is no longer happening, I have to resort to right clicking on the project & clicking publish, which works, but is inconvenient.
What can I do to re-enable this "auto deployment" feature?
So far, I tried:
I looked thru every database related setting in Tools > Options.
I confirmed the Configuration Manager is set to both "Build" and "Deploy" for my database projects.
I confirmed that the LocalDB is installed and working.
I applied all Windows updates & updated VS2012 to the latest version, 2012v4.
I tried all combinations of Clean, Build and Rebuild at the project & solution level.
I checked "Always Re-create Database", and even this doesn't work.
I suspect that this feature might be dependent upon other software or patches that I had on my old installation.
I figured this one out myself.
There is an option that controls how dependent projects are built under the "Projects and Solutions > Build and Run" section. I overlooked this option at first, but eventually came back around to it when I was testing each setting one at a time.
The description of the check box might be incomplete or perhaps I'm just misunderstanding it. This setting appears that it does not affect the build action of the database project, but it does affect the deploy action. When this is checked, my database project, which is not the startup project builds but does not deploy on Run/Debug. When this is unchecked, my database project builds and deploys as I expect with no additional steps required.
I found two alternatives from the accepted answer:
Right-click the solution, select "Startup Project", "Multiple startup projects", and make the database project one of them.
Right-click the solution, select "Project Dependencies", and make the database project a dependency on one of the other projects that will be built.