Many articles state that LocalDb is easy to install and some state that SQL Express is not needed to deploy an application that uses LocalDb. However, I have found no reference that tells what binaries should be included in an install for an application that uses LocalDb.
Do I simply need to add the contents of "\Program Files\Microsoft SQL Server\110\LocalDb\Binn" to the application folder?
Is there a reference on this?
You should still use LocalDB MSI to install it. It is just that LocalDB MSI is very simple, has no prerequisites on supported platforms, installs fast and asks you no questions.
Also, if your application uses ClickOnce installation, and you are using Visual Studio 2012, you can just mark LocalDB as chained dependency in your Deployment Wizard.
Otherwise you need to make sure your installer installs LocalDB MSI.
Related
Is anyone aware of an installer (msi or otherwise) that drops the SSIS Deployment Wizard executable (ISDeploymentWizard.exe) onto a server (generally found in C:\Program Files (x86)\Microsoft SQL Server\110\DTS\Binn). We have a web server (we use this as our TFS Agent) that we want to deploy our SSIS 2012 packages from - it is a fairly vanilla server (with IIS, .NET, etc) and hence we don't want a fully blown install of SSIS and/or VS2012 (SSDT) just to deploy SSIS packages.
I realise we can use T-SQL (which requires an instance level perm'd user as an OPENROWSET BULK import is used) and/or MOM to deploy SSIS packages to a remote SQL Server 2012 instance however the preference is to use the SSIS Deployment Wizard
I would have thought ISDeploymentWizard.exe would have been part of the SQL Server 2012 Feature Pack (http://www.microsoft.com/en-us/download/confirmation.aspx?id=35580) however it is unclear exactly whether this is the case and indeed which msi it would belong to
I needed the same ISDeploymentWizard.exe on our build server. We didn't want a full installation of SQLServer on the build box. Using the ISO (en_sql_server_2012_developer_edition_with_sp1_x64_dvd_1228540) from MSDN subscriptions
I chose "Integration Services"
However, if you look thru the files in the ISO there is
sql_is.msi
Which is likely the MSI you looking for. That placed isdeploymentwizard.exe in for out 64-bit machine.
C:\Program Files\Microsoft SQL Server\110\DTS\Binn\ISDeploymentWizard.exe
I want to use SqlLocalDB for my application. The application is deployed with WiX. Now, I am searching a way to install SqlLocalDB when my application is installed for the first time. How can I do that? Would it be enough to deploy some binaries with my application or do I have to install the whole SqlLocalDB.msi? - When installing of the whole msi is needed - how can I do this with WiX? - The goal is, that the result is a single msi-file which holds all what is needed for installing my application.
I'm not aware of a private deployment model for LocalDB. If WiX is your tool of choice, you'll need to use it's Burn bootstrapper feature to install LocalDB as a prerequisite. The result will be a single EXE that installs 2 MSI's.
I have an application that uses SQLLocalDb that I am deploying via InstallShield Express Spring 2012.
LocalDb requires that the .Net update for KB2544514 be installed. LocalDb is unable to connect to a LocalDb instance without this update.
When I add this exe to InstallShield as a custom action:
An Error 1721 is encountered when NPD40-KB2544514-x86-x64.exe is executed unless the install is run as Administrator.
If the setup that includes NPD40-KB2544514-x86-x64.exe is run as an Administrator, the installation succeeds.
Is there a way to daisy-chain the Microsoft KB update with the install that does not require a reight-click "Run as Administrator". My concern is that instructions "Right click and Run as Administrator" will typically be overlooked by 99% of users and generate a high number of support calls.
You'll have to make a custom prerequisite via the "Install Shield Prerequisite editor" and associate it with your feature.
I am creating msi file using visual studio. But i need to know how to test .Net Framework and SQL server are installed before doing installation of msi.
Is there any settings (Or) any windows installer are available.
Windows Installer proposes use the Bootstrapping for these purposes. You pack your MSI to Setup.exe and set needed prerequisites, in your case .NET FW 4 and SQL. When user starts Setup.exe, it checks if .NET and SQL are installed, if not installs them and then run the your MSI. You could include the installation files of .NET or SQL in your setup.exe or set link from where installation downloads it.
There is more information about Windows Installer Bootstrapping.
Can you please enlighten me on my task?
My task is to create a nightly builds of MSI (done in WiX) and install it to our web server using powershell.
TFSBuild server build an MSI
Run Powershell to uninstall and install the newly build MSI.
Run Powershell to Start the windows service.
The WiX MSI contains WindowsService and a Web Application.
Below are list of what i have done so far:
Solution.sln : Configuration Manager and "x86|debug" (check all the files that needs to be built '.wixproj' already checked)
Created a build definition and set "x86|debug" for configurations to build and set projects to build is my solution file.
but after the build has completed, there is no MSI files on the binaries build folder on the build server. :(
Thanks in advance.
Few pointers:
Have you installed Wix on the buildserver?
Which version of Team Build are you using? 2010 has the preference here as the tooling has progressed a lot since 2008.
Did you configure to run msbuild in auto or x86 mode (auto can result in 64-bit which has some issues with the latest stable version of wix) link link
Is your build agent running on a 64 bit server? If so, you either need to run the build agent under an administrative account or do some mucking around in the registry to fix issues with Wix. link
To install the build using Powershell, I personally prefer TFSDeployer, which can monitor your build output and trigger powershell scripts based on the build outcome. It takes away the deployment responsibility from the build server and saves a lot of headaches around security and account configurations.