I have a solution with multiple (6) database projects that were converted from Visual Studio Database (.dbproj) projects to SQL Server Data Tools (.sqlproj) projects. In Visual Studio 2013, I can successfully build and publish each of the databases to my local SQL Server instance one at a time.
In Visual Studio 2010, I was able to deploy the solution, which in turn built and deployed all the databases. In Visual Studio 2013, deploying the solution does nothing, even though all of the projects are set to both build and deploy for the active configuration.
How can I build and deploy all of the databases from Visual Studio 2013?
If these databases are related somehow and referenced as database references, they will be built and deployed together as one connected solution. Consider the following two scenarios:
Scenario 1:
You have a solution that contain four databases [A, B, C, D]. [A] references [B, D]. [D] references [C]. If you added them as connected databases using Database references and tried to deploy A, all of them will be built and deployed.
Scenario 2:
You have a solution that contain four databases [A, B, C, D]. [A] references [B, D]. If you added them as connected databases using Database references and tried to deploy A, only [A, B, D] will be built and deployed. [C] is an orphan project in the solution ( and actually it shouldn't be in that solution) and it will not be built or deployed by the solution.
I understand it is may be late, but...
We using this way:
Tune you database references in existed sqlproj as you need.
Just make another one project(kind of "lalala_Deploy") and add all existed as references with Database location == "Same database".
Deploy "Deploy" project.
As a result your projects will be builded corresponding their database references and then deployed to single DB.
upd 28.03.2017 17:37:
In 2013 we was use cdm with msbuild command line and publish profiles.
Here is these codes:
CMD example:
%WINDIR%\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe .\ProjectName\ProjectName.sqlproj /t:Build;Publish /p:Configuration=Release /p:SqlPublishProfilePath=ProjectName_local.publish.xml /consoleloggerparameters:Summary /verbosity:normal /l:FileLogger,Microsoft.Build.Engine;logfile=OmniUS_Build.log;append=false
Here is publish profile example:
"<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<IncludeCompositeObjects>False</IncludeCompositeObjects>
<TargetDatabaseName>ProjectName</TargetDatabaseName>
<DeployScriptFileName>ProjectName.publish.sql</DeployScriptFileName>
<TargetConnectionString>Data Source=.\SQL2014;Integrated Security=True;Pooling=False</TargetConnectionString>
<ScriptDatabaseOptions>True</ScriptDatabaseOptions>
<BlockOnPossibleDataLoss>False</BlockOnPossibleDataLoss>
<IncludeTransactionalScripts>False</IncludeTransactionalScripts>
<CreateNewDatabase>True</CreateNewDatabase>
<DropObjectsNotInSource>False</DropObjectsNotInSource>
<AllowDropBlockingAssemblies>True</AllowDropBlockingAssemblies>
<GenerateSmartDefaults>True</GenerateSmartDefaults>
<IgnoreFillFactor>False</IgnoreFillFactor>
<IgnoreFilegroupPlacement>False</IgnoreFilegroupPlacement>
<IgnorePermissions>True</IgnorePermissions>
<IgnoreObjectPlacementOnPartitionScheme>False</IgnoreObjectPlacementOnPartitionScheme>
<IgnoreRoleMembership>True</IgnoreRoleMembership>
<BlockWhenDriftDetected>False</BlockWhenDriftDetected>
<RegisterDataTierApplication>False</RegisterDataTierApplication>
<DisableAndReenableDdlTriggers>False</DisableAndReenableDdlTriggers>
<IgnoreIndexPadding>False</IgnoreIndexPadding>
<IgnoreKeywordCasing>True</IgnoreKeywordCasing>
</PropertyGroup>
<ItemGroup>
<SqlCmdVariable Include="N_Period">
<Value>201410</Value>
</SqlCmdVariable>
</ItemGroup>
</Project>"
In cdm example i left 1 string, but for you case you have to add for each you project. The publish profiles mast be separated for all of projects because they are containg DB name.
Related
I have a solution with multiple projects.
The solution has projects in both C # and VB.
The solution has SDK-style and non-SDK-style projects.
I uses VS2019. It builds the solution without any errors.
My build server is using MSBuild from VS2019 build tools. It founds CS0246 errors in my solution.
Examining the code shows that the problem is the missing project reference. Project dependency hierarchy is shown below:
A - SDK-style C# project
|
+-> B - Non-SDK-style VB project
|
+-> C - SDK-style C# project
The code from project A uses classes from project C. But project A doesn't have project C in its ProjectReference list. It is an error without doubt.
But why VS2019 does not detect CS0246 error?
What should I change in my VS2019 so that it gives me exactly the same build results as the build server?
Version of MSBuild is the same 16.8.2.56705 on build server and on my PC.
Actually, I did not face the same issue in my side.
In my test project,
Project A(a new-sdk style net472 console project）which has a ProjectReference to Project B(a vb net framework 4.7.2 class library project) like this:
Use ProjectReference:
<ItemGroup>
<ProjectReference Include="..\ProjectB\ProjectB.vbproj" />
</ItemGroup>
While Project B also has a ProjectReference to Project C(new-sdk net472 class library project):
<ItemGroup>
<ProjectReference Include="..\ProjectC\ProjectC.csproj">
<Project>{bf3ad507-ed99-486a-b90d-51d8acc25dfc}</Project>
<Name>ProjectC</Name>
</ProjectReference>
</ItemGroup>
In my side, I also uses the function from Project C into Project A and it builds with any errors.
In fact, Project A can obtain the content of Project C through the transfer relationship. The build order is C, B, A. A first visits B to find the method of C. When the reference to C in B is read, there is access to the project of C, so the method of C is obtained. Therefore, there is no need for A to have a reference to C. As long as the order of the dependent layers is correct, there will be no problem.
Then, I passed the whole solution to the build server and then it works well.
So please try the following suggestions:
1) make sure that your build tool has installed the related workload such as .NET Desktop build tool,Net Core build tool, also the related Net Framework version.
2) delete every project's bin and obj folder on the build sever
3) use Build Tool, first restore and then build.
cd xxx\xxx.sln
msbuild -t:restore,build
If your VB project has other nuget packages, you should use nuget restore additionally:
cd xxx\xxx.sln
nuget restore
msbuild -t:restore,build
Besides, if it does work for your issue, please share a small sample here which will help us investigate this issue more efficiently.
Update
Project A:
using System;
using ProjectC;
namespace ProjectA
{
public class Class1
{
static void Main(string[] args)
{
Test te = new Test();
Console.WriteLine(te.Tec(3, 5));
Console.WriteLine(te.Test1());
}
}
}
Project C:
using System;
namespace ProjectC
{
public class Test
{
private int a, b;
public int Tec(int a,int b)
{
return a + b;
}
}
}
Project A references Project B , B references C. And A uses the function from C.
Screenshot
I moved the solution into build sever, and then delete .vs, every bin and obj folder and then run these commands, no error occours.
Maybe there is something wrong with your build sever. Please click Repair from VS Installer for the build tool. Or just reinstall build tool.
It seems that the issue was fixed in VS 16.8.4:
Issued Addressed in this Release of Visual Studio 2019 version 16.8.4:
Transitive project references are now respected when a PackageReference projects >references packages.config projects with PackageReference dependencies.
We had the same issue and now it works fine.
Is there a way to tell Visual Studio to build projects that aren't part of its solution? We've been looking into many different options without success such as nested projects, shared projects, and build events.
Example architecture:
Project A
Project B
ref Project i
ref Project ii
Project C
--------------
Solution 1
Project A
Project B
Project C
Solution 2
Project i
Project ii
Right now, I can't build Solution 1, because Project B won't build, because Projects i and ii haven't been built. I have to switch to Solution 2, build that, and return to Solution 1 and then the build works. This doesn't sound like the best way to do things, but I'm not the one to decide and am looking for a way to ease the process without adding Projects i and ii to the solution itself, even though adding some build events or whatnot to the solution would be permitted. How can I achieve this?
The solution we've come up with was to add a pre-build target in the C# projects that have project dependencies outside the solution. Namely, Project B now contains something like this:
<ItemGroup>
<ProjectDependency Include="..\Solution2\Project-i.csproj"/>
<ProjectDependency Include="..\Solution2\Project-ii.csproj"/>
</ItemGroup>
<PropertyGroup>
<BuildDependsOn>
BuildProjectBDependencies;
$(BuildDependsOn)
</BuildDependsOn>
</PropertyGroup>
<Target Name="BuildProjectBDependencies">
<MSBuild Projects="#(ProjectDependency)"
Properties="OutDir=$(OutputPath);
Configuration=$(Configuration)"
Targets="Build" />
</Target>
Attempting to build Project B first requires Project i and Project ii to be built, whether this is in Visual Studio or using an automated build process.
MSDN docs Visual Studio Integration (MSBuild) state:
Building Solutions
Within Visual Studio, the solution file and project build ordering are
controlled by Visual Studio itself. When building a solution with
msbuild.exe on the command line, MSBuild parses the solution file and
orders the project builds. In both cases the projects are built
individually in dependency order, and project to project references
are not traversed. In contrast, when individual projects are built
with msbuild.exe, project to project references are traversed.
With my Visual Studio 2010, when building a .sln file with MSBuild from the command line, project to project references are all built, regardless whether they occur in the solution.
What did I miss here? Or are the docs plain wrong?
You are correct that msbuild.exe will sort out all project references whether or not they are part of the solution in contrast to building within Visual Studio 2010/2012/2013/2015 (and possibly later versions) where you will get a build failure if a referenced project is not part of the solution or built beforehand.
In short, yes, the documentation seems a bit off.
You can ignore the build of project to project reference by running msbuild Solution.sln /t:ProjectName /p:BuildProjectReferences=false this explain the sentence in msdn.
I have an SSDT project where I recently changed from SQL 2008 to SQL 2012. I re-exported my references DACPAC files using the SQL 2012 SqlPackage and replaced the SQL 2008 DACPACs with the new 2012 versions. Now I am getting unresolved reference errors for all of the referenced databases.
Strangely enough, IntelliSense auto complete works with the objects in the DACPACs. I can get all tables and columns to auto-complete and show their datatypes, even on the object SSDT is complaining about.
Is there a know issue with SSDT when migrating versions? I have another project using these DACPACs and it builds without error.
I would do three things, the first is double check that each dacpac is at 2012 - when I had a mixed project it was a nightmare, mixing versions causes all sorts of issues with references.
Secondly, open each of the dacpacs as a project in Visual studio and make sure that each of them build correctly, it might be a reference from one of those to something in master etc that is causing subsequent build failures.
Finally do a clean of the solution and build just the dacpac project, look for any messages or warnings in the output window, the answer will be there but just hard to see.
ed
It seems that since VS2010 and MSBuild 4.0, VisualStudio and MSBuild are able to resolve and build project references that are not located within the solution.
Let us create an example to be more concrete. Create a solution called Solution1 with a C# project named A and another project called B. In project B, add a reference to project A. Now create a new solution called Solution2 and click "Add Existing project" and select Project B. There is a warning that can be seen in Solution Explorer and the Warning List.
The trick is that even with "warning as error" we are able to build Solution2.sln. Actually, project A is found
and built by Visual Studio or MSBuild. Let us verify this by opening a VS2010/VS2012 command line and execute the following commands:
msbuild <dirPathToSolution1> Solution1.sln /t:clean **cleaning up solution1 with project A"
msbuild <dirPathToSolution1> Solution2.sln /t:build
ProjectA is effectively built and worse: the warning mentioned above is not even raised there. With previous versions of Visual Studio such situation could not happen (I have tested it with msbuild 3.5 and VS2008).
However, in our situation we would like to prevent such things. Indeed, we have a large source repository with several solutions and many committers. We are reorganizing our dependencies aiming finally to the extraction of smaller repositories. Meanwhile, we do not want developers to add hidden project dependencies without seeing it. We would like to allow only project references "inside" a solution, leaving other dependencies to assembly references.
So the question is "Is there a way, to prevent such solution such as Solution2 to build ?". Ideally, it should not compile with both VS2012 and MSBuild. However a solution involving only the MSBuild command line would do thanks to our Continous Integration.
edit I checked Microsoft.Common.Targets and there does not seem any way to achieve what you want. Either project references are built, or they are not (this is for instance influenced by the BuildProjectReferences flag of my original answer). There is no way to build them selectively depending on which solution they are in unless I'm missing something - which is mainly because project references are set on the project level, not on the solution level: in your project file there is an MsBuild ItemGroup named ProjectReferences and that is used. (Actually this makes some sense: if you ask MsBuild to build projectB.csproj, and B says it references A, then no solution comes into play and you could expect it to build A, after all you are referencing it).
Now as I understand it, you want to prohibit referencing across directories whose structure happens to be represented by solutions. If that is the case, and you really need this, you could probably get away with a tool that parses the MsBuild log and looks for lines like
Project "somedir\projectB.csproj" (2) is building "someOtherDir\projectA.csproj" (3) ...
then extract the directory info from it and make the tool raise an error when they do not match. Then incorporate the tool in your CI server and feed it with the msbuild log files.
original answer
Try with /p:BuildProjectReferences=false on the command line. As the name suggests it will disable building of referenced projects. When building solution1, this should not be a problem since projectA will be built anyway as it is in the solution. However when building solution2, it won't build projectA and you'll get a build error.