Following is the exact scenario in my database project, where I am creating dacpac to deploy databases on target SQL instance:
the database project is having a reference of CLR assembly.
TFS build server is used to build the project
dacpac is getting created during TFS build process
– when i try to run sqlpackage.exe to deploy the dacpac (generated in TFS build process) in my environment, I get an error saying –
*** No file was supplied for reference XXXX.XXXX.XXXX.dll; deployment might fail. When C:\Temp\Dacpac_testing\XXX.XXXXX.XXXX.dacpac was
created, the original referenced file was located
C:\BUILDS\1\XXXX\XXXX\SRC\XXXXXXXX\ASSEMBLIES\XXXX.XXXX.XXXX.dll
How can I create a dacpac to reference the path of CLR assembly on deployment environment (and not the one that was used at the time of building dacpac)
Any help on this will be much appreciated.
Sorry I only picked on this thread now, but I had a similar issue.
Open the references in the Sql Server project, go to the dll that you are referencing right click and select properties.
Change the following settings:
Generate Sql Script: True
Model Aware: True
Select the relevant Permission set as required by the clr code.
I was able to solve this issue by including all the files in the bin/output folder that is built by the SSDT project on the machine that is deploying the dacpac. This folder includes all the referenced DLLs and DAPACs. I also included the publish.xml file and some sample SQLPackage cmd files in the build output to make it easy to deploy.
I found the answer from a post by Richard Gavel in the SQL Server Data Tools forum.
https://social.msdn.microsoft.com/Forums/sqlserver/en-US/aba60b70-396f-4624-890c-015c1f2d68f7/dacpac-dependencies-for-sqlpackageexe?forum=ssdt
I don't know if this helps but I was having trouble running SqlPackage /Action:Script between my compiled DACPAC and an extracted DACPAC and got a similar error (An error occurred while adding references). I resolved it by copying all the DACPACS from the \bin\debug directory of my DACPAC (it has about references to 15 other database projects plus master and msdb). After that, it worked. So it seems that in looking for references, it will check the directory first (I don't know if it was looking specifically at the current directory or the one the root DACPAC was in because those were one and the same).
Related
VS2017, Deploy to SS2016. Package runs without any errors from VS. Project deployment to a server that previously had package deployments only - we're moving to project deployment, and DBAs said to use that.
Getting many errors like:
Get Error Information:Error: Failed to compiled scripts contained in the package. Open the package in SSIS Designer and resolve the compilation errors.
The package has absolutely no script objects. I've checked with the package explorer, and there isn't even a scripts section. To verify, I added an empty script, and then the explorer did show that section.
Other info: Package deployment is new to our DBAs. They are completely mystified by this, and other errors, like:
Get Error Information:Error: CS2001 - Source file 'C:\Windows\TEMP.NETFramework,Version=v4.0.AssemblyAttributes.cs' could not be found, CSC, 0, 0
My opinion, unexpert in SSIS as I am, is that these servers are not set up or configured properly in some way, but I am out of my depth in this, and DBAs are floundering. What might I do to get to the root of this?
I ended up side-stepping the issue by essentially recreating the package. Even XML search revealed no scripts, so the assumption was some kind of corruption. The package was recently upgraded to package-deployment - perhaps that action had a hand in the problem.
We had the same issue and isolated the problem to a Script Task (regardless of language) that existed in a Sequence Container. Placing the Script Task outside the Sequence Container, and upgrading the package to 2016 worked. The package was originally 2012 (as far as I can see) and the server side SSIS was 2016 13.2.5426.0. We were using VS 2017 as well.
For me this was happening because I was targeting the wrong database version. in your SSIS Package project go into properties and set the TargetServerVersion appropriately And then recompile the project and redeploy to sql server.
I have a problem with unresolved referenced in synonyms with a VS2013 Database project I have created for Team Foundation Server, which cause the project to not build. The synonyms reference another Database on the same server. I have seen online there are 3 main ways people handle this. I am going for this approach 1.
Create a DPAC file and add as a Database reference in Visual Studio Database Project.
Bring in the other database project in the current team Foundation Server project ?
Set the build action to None for the failing scripts that have the unreferenced synomns.
So when I go to extract the DPAC file from the Database it fails with an error.
Validation of the schema model for data package failed.
Error SQL71564: Error validating element [UAT_*********]: The element [UAT_*****] has been orphaned from its login and cannot be deployed.
( There is about 9 similar messages with other logons as well)
Is there anyway to bypass this and generate a valid DPAC file from sql server ?
If you need a .DACPAC file as a reference to your database projects, there is no need for referencing object to have any real code - As long as the signature met the requirements that the reference from Database Project was looking for, it will be just fine (syntactically valid).
You do not have to create a .DACPAC directly from SQL Sever, you can create a new empty Database Project, create/import all objects needed as references and then "Snapshot Project". This will generate valid .DACPAC and keep the size to minimum, which then you can put under source control.
If you wanted to create a .DACPAC from SQL Server, then I am afraid you would have to delete those objects, because it is unable to find logins in master database that are associated with them.
Great article to read about your approach 1 :
A complex database project
Hope this helps.
I want to use database project for script deployment in Azure SQL Server, I don't want to import full database. I just want to use database project for delta script. I added a project and included one script file with none as build action that contains create table statement , I am publishing the project, It's completing successfully but create statement is not executing. What is wrong here? Is there any other way to do this?
TLDR: Set your build action to "Post Deployment Script".
Longer:
What happens in SSDT is that all the files that have a build action of "Build" are built into a model of what the database should look like. When the deploy happens that model is compared to the target database and if there are any changes, a change script it generated and then optionally deployed.
If you have any file marked pre or post deployment script then they are either prepended or appended to the change script and will be run as part of the deployment.
If you have any files with a build action of "None" then SSDT ignores them, you could put anything in there, even an ascii picture of a donkey and the project will still build and deploy (obviously your ascii donkey won't get deployed anywhere).
If you just want to use SSDT to do your deployments you can just set the build action to pre or post deploy and it will be included. This is pretty odd though, either don't use SSDT or use SSDT and put the model of your entire database in there.
Personally, I would use SSDT properly and live the dream.
Ed
I'm trying to generate an output dacpac file which I can then deploy to different environments. Until now I was deploying directly from msbuild using the target publish, something like:
msbuild dbproject.sqlproj /t:Build;Publish /p:SqlPublishProfilePath=test.publish.xml /p:UpdateDatabase=True /p:PublishScriptFileName=test.sql
The size of the ouput script generated (just for reference as UpdateDatabase is set to true) is 2.5MB.
My new approach is to just build the project, store the dacpac and then deploy using sqlpackage with action 'Publish'. This new method is reporting some warnings which were not reported by msbuild SqlPublishTask.
For reference I ran the next command:
sqlpackage.exe /action:script /outputpath:test.sql /sourcefile:dbproject.dacpac /pr:test.publish.xml
and the size of the output script is now 4.9MB.
The specific warnings reported are not the concern here, the concern is that the script is different, my question is what is the difference?
and more importantly which one would be the best/safest method to do the deploy?
Sqlpackage.exe is more detailed and includes more objects during the deployment, it drops the permissions to tables to avoid any modification during the modification of the objects and then it proceeds to create or modify the them.
The difference is that ALL the objects are included in the script of sqlpackage, independently on whether they are different or not from the target database.
Although the warnings given were not a concern initially, using the sqlpackage method I discovered that some store procedure were not in the solution, only in the database. These 'orphan' sp were referencing tables being deployed, which is giving a warning stating that a change in the table may break the sp.
This might be a very trivial question but deployment is new to me and little confused about which file to deploy.
I have a WPF test project uses Entity framework in visual studio and trying to use WIX to deploy it. Target machine is running windows 7. Given that .Net Framework and sql server localdb is installed on the target machine what files I need to deploy (make component in the WIX xml file)? I have tried copying the whole bin/Release folder to the target machine and it works. However I don’t know if that is necessary. The following screenshot shows the bin\Release directory of my application.
The problem is I don’t know the job of some files particularly the files with the following extensions:
.exe.config
.pdb
.vshost.exe
.vshost.exe.config
The database file is located in the Users\[username] directory and gets created if it doesn’t exist so I suppose it’s not part of the deployment.
Additionally I would like to understand two xml files-
EntityFramework.SqlServer.xml
EntityFramework.xml
Do I need to deploy these two files as well?
exe.config
Several settings you can change here - if defined in the Project building the EXE. You probably want to deploy this.
.pdb
Debugfiles. Deploy if you are investigating errors - else don't, these contain source information.
.vshost.exe
.vshost.exe.config
Do not deploy. These are used/generate by Visual Studio. If you start a Project out of Visual Studio it is ran in a hosted process environment so it cannot crash Visual Studio when then application runs into an error. Not for production.
EntityFramework.SqlServer.xml
EntityFramework.xml
This is documentation for the corresponding dlls. Useful for development, I do not think you want to deploy them thou.