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.
Related
i have developed application using vb.net for windows system. which have sql server 2008 database and also includes crystal reports. and i want to create .exe of project. For distribution.Then how can i do that. Please help.. I am trying to do this with visual studio 2010.. Using traditional method...
1.Go to File | Add and click New Project.
2.In the Add New Project dialog box, select Other Project 3.Types and choose the Setup And Deployment Projects folder..and so on..till adding project output and primary output.but after clicking on primary output it give message like..The following files may have dependencies that can not be determinited automatically. Please confirm that all dependencies have been added to the project c:\windows\system32 \macromed\flash\flash.ocx.. Please help me to solve this..
Your question and your error arent related.
For your client, you need to install Sql Express.
LocalDB deployment on client PC
For the flash error, you need to check where you are using flash and make sure is also installed.
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).
I've created an Umbraco project locally following instructions from here:
https://our.umbraco.org/documentation/using-umbraco/creating-basic-site/
VS version: VS 2013 Pro
Umbraco version is 7.2.1
SQL version: SQL Server 2008 r2
All working fine locally, created master template, some page templates and some content. Now I would like to push the site live, both layout and content, using an Azure Website. I created the SQL DB on Azure using the app from:
https://sqlazuremw.codeplex.com/
I've verified the DB looks correct by doing a Schema compare and Data compare through VS SQL Server Object Explorer.
I published the site via VS 2013, right click project, publish, Azure Web Site and all went through as expected.
Problem
When trying to view the site it's just returning a blank page, no HTML in the source. Looking at the files which have been uploaded to Azure, it appears that some files from the Views directory weren't uploaded e.g. ContentMain.cshtml, Homepage.cshtml, Master.cshtml.
Looking at my local project source, none of those files are included in the project i.e. the icon has a dotted outline. Presumably this is something to do with the fact they were originally created via the browser?
Is it expected that those files aren't supposed to be part of the project and therefore aren't included when publishing to Azure?
I'm guessing that it would work fine if I simply right click and include each of the files then re-deploy. However I don't want to cause some other issue in Umbraco by doing so.
What is the best practice advice to get round this?
Cheers,
Lee
Is it expected that those files aren't supposed to be part of the project and therefore aren't included when publishing to Azure?
I'm guessing that it would work fine if I simply right click and
include each of the files then re-deploy.
I think it's correct. Templates created by Umbraco back-office are not included automatically in Visual Studio Project and VS cannot publish items not included in project.
A better approach is to create your templates directly in your VS Project.
This seems like it would be easy as pie but it is not. I would like to include a sql server database with my application installation. I see a lot of similar questions, so let me be clear: I know how to set up prerequisites, but I want to include my application's database with the installation.
I am using Visual Studio 2010. I have a project with a local database. I have a setup project. However, when I generate the setup.exe and install the app, no database is generated and the app does not work.
I hope that the answer to this is as simple as it seems it should be. How do I include my application's database with the rest of the application in the setup.exe?
Got it! My solution:
In the setup project right click the project and select View > File System. Then right click the Application Folder folder and select Add > File...
Then browse to .mdf file, select it and bam! Included in the installation.
I'm just trying to understand SSIS packages a bit better and how they are deployed. Correct me I'm wrong but for any deployment, I believe there needs to be at least two files a .SSISDeploymentManifest and a .dtsx. The .SSISDeploymentManifest acts as the equivalent windows installer package which points to the .dtsx. The dtsx is the actual package of "stuff" that is referenced as an external file some how when you run the installer. When you install it, the package gets added to a list of ssis packages for that instance.
My further questions:
If i wanted to keep previous version of the same package, can I just copy the bin directories with the two above files and keep separately should I need to roll back to a previous package?
Where are these packages installed to? How does SSIS know where the packagess are?
Correct me I'm wrong but for any deployment, I believe there needs to
be at least two files a .SSISDeploymentManifest and a .dtsx. The
.SSISDeploymentManifest acts as the equivalent windows installer
package which points to the .dtsx. The dtsx is the actual package of
"stuff" that is referenced as an external file some how when you run
the installer. When you install it, the package gets added to a list
of ssis packages for that instance.
Your assumptions are mostly correct. You don't need the deployment manifest, but it can be handy. Also, you don't need to deploy to the SQL Server instance. You have the option to deploy to the file system as well. I'll explain both below.
Regarding your 1st question:
Version Control:
Make sure you're developing and checking in your dtsx packages via visual studio. Label your releases in sourcesafe or whatever version control you're using. If you are checking in and labeling, then you should be able to easily roll back to a previous version. As you mention, you also can just save a copy of your old bin directory but naturally put them in dated subfolders or something. However, this does not take the place of proper version control.
Regarding your 2nd question:
Deployment:
As the other poster states, you first have a decision to make:
a) Deploy packages to the file system
b) Deploy packages to MSDB
There are benefits to each, and everyone has their preference. I have used both, but I prefer the filesystem because it's more transparent, however there is more to maintain.
See this post for much more on this: http://blogs.conchango.com/jamiethomson/archive/2006/01/05/SSIS_3A00_-Common-folder-structure.aspx
The code is in the dtsx package. Generally,in order to make your packages portable you also abstract your connection strings and other configurable information into a config file (.dtsconfig) or environment variable (no file needed). See BOL to learn more about configuration.
The manifest file contains metadata about which dtsx and config files to install. If you open one, you'll see it's a simple readable xml file.
The manifest file makes it easy to hand over to a DBA to deploy (ask them to double-click the manifest file and follow directions, but they'll need instructions.
To me, the manifest file is more useful for deploying to SQL Server than to the file system. Really, all it does is make a copy of the dtsx and config files and puts them where you tell it. You could just as easily instruct the DBA to copy your dtsx files to a common folder on the server, and the config files to another folder on the same server.
Then when you schedule your jobs using SQL Agent, you specify that you're going to run an SSIS package that is stored on the file system and browse to where it's located. If you're using configurations, then there's a tab to specify where the config file is located.
There is so much to know about configuring/deployment/versioning of SSIS packages. But hopefully this will get you started on the right path.
When you export your DTS packages using the Import/Export Wizard in SQL Server you have the option of saving them to SQL Server or locally on the file system.
Regarding the versions of your SSIS packages, you need to query SSISDB to extract the version numbers. It's annoying this kind of info isn't shown directly in the Management Studio but, until it is, someone may find this useful:
SELECT prj.[name] as Project
,pkg.[name] as Package
,pkg.[version_major]
,pkg.[version_minor]
,pkg.[version_build]
FROM [SSISDB].[internal].[packages] as pkg
JOIN [SSISDB].[internal].[projects] as prj
ON pkg.[project_id] = prj.[project_id]
ORDER BY prj.[name]