I'm setting up database projects for the first time and I'm trying to build/deploy using Azure DevOps. I'm using the MSBuild task hosted in Azure (windows-2019) for the build. I'm using a Command Line task running on the SQL server to execute SQLPackage.exe from a working directory of
C:\Program Files (x86)\Microsoft Visual Studio\2019\BuildTools\Common7\IDE\Extensions\Microsoft\SQLDB\DAC\140.
I'm getting errors for the master & msdb databases during deployment with SqlPackage.exe:
No file was supplied for reference master.dacpac; deployment might fail. When C:\Jen_DacpacTest\Artifact\whatever.dacpac was created, the original referenced file was located C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\ENTERPRISE\COMMON7\IDE\EXTENSIONS\MICROSOFT\SQLDB\EXTENSIONS\SQLSERVER\140\SQLSCHEMAS\MASTER.DACPAC.
I thought that the references to master and msdb were resolved on build and again on deploy (since it's a variable for the path) but that doesn't seem to be the case. It seems to figure out what $(DacPacRootPath) is during the build and "hardcodes" the references in the model.xml file generated into the dacpac. The references look like this in the proj file:
<ArtifactReference Include="$(DacPacRootPath)\Extensions\Microsoft\SQLDB\Extensions\SqlServer\140\SqlSchemas\master.dacpac">
<HintPath>$(DacPacRootPath)\Extensions\Microsoft\SQLDB\Extensions\SqlServer\140\SqlSchemas\master.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
<DatabaseVariableLiteralValue>master</DatabaseVariableLiteralValue>
</ArtifactReference>
<ArtifactReference Include="$(DacPacRootPath)\Extensions\Microsoft\SQLDB\Extensions\SqlServer\140\SqlSchemas\msdb.dacpac">
<HintPath>$(DacPacRootPath)\Extensions\Microsoft\SQLDB\Extensions\SqlServer\140\SqlSchemas\msdb.dacpac</HintPath>
<SuppressMissingDependenciesErrors>False</SuppressMissingDependenciesErrors>
<DatabaseVariableLiteralValue>msdb</DatabaseVariableLiteralValue>
</ArtifactReference>
Here's what it looks like in the model.xml file if the dacpac is unpacked:
<CustomData Category="Reference" Type="SqlSchema">
<Metadata Name="FileName" Value="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\ENTERPRISE\COMMON7\IDE\EXTENSIONS\MICROSOFT\SQLDB\EXTENSIONS\SQLSERVER\140\SQLSCHEMAS\MASTER.DACPAC" />
<Metadata Name="LogicalName" Value="master.dacpac" />
<Metadata Name="ExternalParts" Value="[master]" />
<Metadata Name="SuppressMissingDependenciesErrors" Value="False" />
</CustomData>
<CustomData Category="Reference" Type="SqlSchema">
<Metadata Name="FileName" Value="C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\ENTERPRISE\COMMON7\IDE\EXTENSIONS\MICROSOFT\SQLDB\EXTENSIONS\SQLSERVER\140\SQLSCHEMAS\MSDB.DACPAC" />
<Metadata Name="LogicalName" Value="msdb.dacpac" />
<Metadata Name="ExternalParts" Value="[msdb]" />
<Metadata Name="SuppressMissingDependenciesErrors" Value="False" />
</CustomData>
So I'm wondering how this is supposed to work since Azure MSBuild task (and Visual Studio build task) which are hosted in Azure will reference the master and msdb dacpacs from a Visual Studio Enterprise folder but on the SQL Server which is where SqlPackage.exe is run to do the deployment those files are found in the BuildTools folder instead of Enterprise. (And I don't really think I should have to install VS Enterprise edition on my SQL server to get this to work?)
In Azure:
C:\PROGRAM FILES (X86)\MICROSOFT VISUAL STUDIO\2019\\**ENTERPRISE**\\COMMON7\IDE\EXTENSIONS\MICROSOFT\SQLDB\EXTENSIONS\SQLSERVER\140\SQLSCHEMAS
On the SQL Server:
C:\Program Files (x86)\Microsoft Visual Studio\2019\\**BuildTools**\\Common7\IDE\Extensions\Microsoft\SQLDB\Extensions\SqlServer\140\SQLSchemas
It seems weird that the path to these files on the build server would have to exactly match what's on the sql server. I thought there would be a bit more magic happening to find these dacpac references since from what I understand you aren't supposed to manually add them to your project and drag them around everywhere.
Database projects deployment - No file was supplied for reference
master.dacpac
This is a typical SSDT issue. The path to these files on the build server is not the main cause of your issue.
Please check No file was supplied for reference ABC.dacpac; deployment might fail and Error: The reference to external elements from the source named 'master.dacpac' could not be resolved.
Try copying the master.dacpac to the same folder where your xx.dacpac exists. (You can do this by using copy/xcopy command in cmd) And make sure the working directory of your CMD task is in same folder. Hope it helps :)
Related
I try to add a folder and its subfolders (~4000 files) as content to a C++ windows store app (in VS2015).
Heres the scenario:
G:\Game -> is the build directory
D:\data -> holds the original content
I've read there are some methods to declare external content in the .vxcproj file like that:
<ItemGroup>
<Content Include="D:\**">
<Link>%(RecursiveDir)%(FileName)%(Extension)</Link>
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<DeploymentContent>true</DeploymentContent>
</Content>
</ItemGroup>
This actually copies the contents of D:\data into the build-directory (G:\Game). This is great since the program can now be run & debugged. BUT: as soon as i deploy the project to the AppX Folder (G:\Game\AppX) the data-folder doesnt get deployed there.
G:\Game\game.exe
G:\Game\data\...
G:\Game\AppX
G:\Game\AppX\game.exe
(G:\Game\AppX\data\... - missing)
Any clues ?
After fiddling around for days, as of now i can state there is no way to do this properly in the Visual C++ - IDE (2012 / 2015) (it seemed to work with C# projects though).
The only way to achieve what i wanted to do is
a post-build-event using robocopy to copy/synch the data over to the AppX folder
Writing a script for the packaging / signing using MakeAppX.exe, SignTool.exe and 7-zip.
I am trying to convert our repository from TFS 2012 on-premise to Visual Studio Online.
I am getting errors like this:
OH-SCM-009: Error occurred while sync. TF203013: The path O:\somepath\Jeffkn~1.jpg is in the DOS (8.3) short path format and is not supported. Enter a full path to the item and try again.
I believe we did this during our migration back in the day (method 2):
https://support.microsoft.com/en-us/kb/951195
Which is to add <add key="allow8Dot3Paths" value="true" /> to our TFS temporarily during a migration.
How do I accomplish this today with Visual Studio Online / OpsHub?
Thanks!
The path contains a file name that is in the MS-DOS-compatible short name format (in your case is Jeffkn~1.jpg), you need to change the path to rename the Jeffkn~1.jpg file, for example Jeffkn.jpg.
Additionally, you can't take Method2 in the KB article to enable TFS2012 Application Tier server to allow the MS-DOS-compatible short name format, because there is no problem to have this path in on-premise TFS, you have the problem when migrate item to VSO. So, you need to enable the MS-DOS-compatible short name format for VSO, but I don't think you have permissions to do it.
Could you Please try below steps, it might help
First close the migration utility then add the app setting key "allow8Dot3Paths" to devenv.exe.config ("c:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE) or in "c:\Program Files\Microsoft Visual Studio 11.0\Common7\IDE
Under the <configuration> element, locate the <appSettings> element, and then add the following element.
<add key="allow8Dot3Paths" value="true" />
in the devenv.exe.config file.
Now start the migration utility, start the migration and retry the failure, wait for the retry to complete and if you still get the error then please email us the OpsHubTFSService.log file from location "C:\Program Files\OpsHub Visual Studio Online Migration Utility\logs" to support#opshub.com
I have a Build server and i would like to copy the newest deployment file from that location to another location on remote server using MSBuild but i am stuck on doing this as well as confused.
So in my build output directory i have a files such as this:
Installer - 2.5.1403.1201.msi
Installer - 2.5.1405.0701.msi
Now i want to copy the newest file Installer - 2.5.1405.0701.msi to remote server called ServerB.
I read that using PSExec shouldn't be used for copy files from build server to another server. Is there a reason why?
Currently i have the following code but i only got it to work locally on my machine:
<ItemGroup>
<File Include="C:\\LocalCopy\\Installer - 2.5.1403.1201.msi" />
</ItemGroup>
<PropertyGroup>
<DestinationFolder>C:\\Dump</DestinationFolder>
</PropertyGroup>
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Target Name="AfterBuild" Inputs="#(File)" Outputs="#(File -> '$(DestinationFolder)\% (RelativeDir)%(Filename)%(Extension)')">
<Copy SourceFiles="#(File)" DestinationFolder="$(DestinationFolder)" />
</Target>
Can someone provide me with advice how i could go about doing this?
Thanks & Regards,
I have created one custom assembly and this assembly uses a third party assembly.
I have deployed a custom assembly in my local machine. But now, what should I do to deploy the report and those assemblies in the production environment. Is there any automated/wizard process available?
You need to copy that assemblies to production server into
Microsoft SQL Server\MSSRS\Reporting Services\ReportServer\bin folder.
Then back to ReportServer folder and open rssrvpolicy.config file to grant FullTrust permission to CodeGroup with name Report_Expressions_Default_Permissions and CodeGroup with class name FirstMatchCodeGroup.
You can copy your library to the ReportServer\Bin folder
ex: C:\Program Files\Microsoft SQL Server\MSRS10_50.R2\Reporting Services\ReportServer\bin
Then modify the rssrvpolicy.config in ReportServer folder, find "$CodeGen$" and add the following code
<CodeGroup
class="UnionCodeGroup"
version="1"
PermissionSetName="FullTrust"
Name="CoDeMagSample"
Description="CoDe Magazine Sample. ">
<IMembershipCondition
class="UrlMembershipCondition"
version="1"
Url="C:\Program Files\Microsoft SQL Server\MSRS10_50.R2\Reporting Services\ReportServer\bin\YOURLIBRARY.dll"
/>
There's a tool for that. It's called Reporting Services Scripter
Another option is to connect to your production server through SSRS.
I'm trying to get MSTest.exe to run, and it seems like testcontainer isn't being read properly; while my tests all run successfully in all config environments within Visual Studio.
the command I'm using is:
"C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\MSTest.exe" /nologo /usestderr /testSettings:"C:\temp\MyProject\Sources\MyProject\Local.testsettings" /searchpathroot:"C:\temp\MyProject\Binaries" /resultsfileroot:"C:\temp\MyProject\TestResults" /testcontainer:"C:\temp\MyProject\Binaries\MyProject.Services.Server.UnitTests.dll"
The project references within testcontainer project look like this:
<ItemGroup>
<ProjectReference Include="..\..\Services\MyProject.Services.Server\MyProject.Services.Server.csproj">
<Project>{92EC1999-CC0C-47DD-A4D6-17C3B1233C50}</Project>
<Name>MyProject.Services.Server</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Interfaces\MyProject.ServiceConfiguration.Interfaces.csproj">
<Project>{8E2E7BA9-75DB-458E-A184-AC1030EAD581}</Project>
<Name>MyProject.ServiceConfiguration.Interfaces</Name>
</ProjectReference>
<ProjectReference Include="..\..\SvcConfiguration\MyProject.ServiceConfiguration.Services\MyProject.ServiceConfiguration.Services.csproj">
<Project>{39514766-23A8-45DB-96EA-B6B4D9C8B086}</Project>
<Name>MyProject.ServiceConfiguration.Services</Name>
</ProjectReference>
</ItemGroup>
Neither the ServiceConfiguration.Interfaces nor the ServiceConfiguration.Services DLL is placed into the Out folder in TestResults.
The project GUIDs do match between the references and the referenced projects.
Is there something that I'm missing in the command line?
mstest.exe will not coy all referenced dll's.
See a blog post on this at https://web.archive.org/web/20111221110459/http://www.dotnetthoughts.net/2011/11/22/mstest-exe-does-not-deploy-all-items/
You can specify exactly what files are copied to the test directory using a test settings file. You can create multiple test settings files in Visual Studio, so you can have one for running from VS, another for running from MSTest, another for server CI builds, and so on. See here for more information: Create Test Settings to Run Automated Tests from Visual Studio
Use the /testsettings:<filename> option to specify it on the command line.
What seems to confuse people at first is that, by default, MSTest's "current directory" is not the MSTest launch directory, but the Out folder of the test results.
As mentioned previously, MSTest does not correctly infer all used assemblies, if you don't have a direct reference, it will not copy the assembly. That said, Visual Studio has similar behaviour in its build too, so a lot of people work around this by adding bogus code references - a terrible solution - I don't recommend it.
However, native DLLs are even more problematic, and I have found that explicitly copying them in the test configuration (test settings) works for them, just as for managed assemblies.
Whether it goes to Out or the build area depends on different factors, however, for the situations where it still doesn't work, you can use a DeploymentItem "hack", or, tweak your runsettings file.
Try looking at this answer: https://stackoverflow.com/a/33344573/2537017