For a simple test I created a Wix installer app for a simple Winform app as follows. But when I run the msi created with the installer it runs for just one second and exits without installing the Winform app. Question: What could be the issue here? It seems something is missing in my Product.wxs file. Note: I'm using VS2017
Steps to produce the issue
Installed Wix Toolset Visual Studio 2017 Extension from here and followed their instructions to install WiX 3.11 RC2 from here
Created a default Winform project [just one single form nothing added to it]
Created a Wix Setup project by using Toolset\v3\Setup Project template in the same solution
In WiX Setup project Added a reference to Winform project
Built the entire solution.
Right clicked the Setup project and re-built it that created an .msi file in its \..bin\Debug folder
Double clicked the .msi file from step 6. File ran for one second, windows 10 installation dialog appeared (as it appears for any installation asking you if you want to install this program). I clicked Yes. Installer ran for one second again then exited. But the Winform app was not installed.
Default Product.wxs file [I did not add anything here except for adding a value to Manufacturer attribute]
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<Product Id="*" Name="SetupProject1" Language="1033" Version="1.0.0.0" Manufacturer="WiX_test_4_Winfrm" UpgradeCode="e69fe67b-5c28-4764-8196-a6613b840eff">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<MediaTemplate />
<Feature Id="ProductFeature" Title="SetupProject1" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="SetupProject1" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!-- TODO: Remove the comments around this Component element and the ComponentRef below in order to add resources to this installer. -->
<!-- <Component Id="ProductComponent"> -->
<!-- TODO: Insert files, registry keys, and other resources here. -->
<!-- </Component> -->
</ComponentGroup>
</Fragment>
</Wix>
WiX Resources: A couple of links first:
WiX quick start resources.
Hello WiX C# Custom Actions.
"Hello WiX" (transparent aluminum please)
I think what you need is the "Hello World" of WiX from CodeProject. This is quite old now, but still good at showing you the very basics of getting a working MSI compiled.
UPDATE: Below I have added a step-by-step description of how to compile an MSI from a fresh WiX 3 Visual Studio project.
Here is another answer from way back with some context information for what WiX really is: MSI vs nuget packages: which are is better for continuous delivery?. You will find the link to "hello world" here as well, but also several other links.
In summary: check the first link to get the "hello world" of WiX. Then update your source with a couple of test components and recompile. You should get hold of Orca (SDK tool) to be able to view the compiled MSI files. Since you have Visual Studio installed, try searching for Orca-x86_en-us.msi and install it (this is Microsoft's own, official MSI viewer and editor). Then find Orca in the start menu. Technically Orca is installed as part of Windows SDK (not Visual Studio), but Windows SDK is bundled with the Visual Studio install. Once you have a compiled MSI file, just right click it and select Edit with Orca.
Some experience will be needed before such a file really makes sense. In essence it is a primitive MS SQL database stored in a COM structured storage file (OLE). Essentially a file system in a file with streams for different content (such as files, and datatables, etc...). Just think of it as a database with normal referential integrity and focus on the core tables such as File and Component at first.
Minimal WiX MSI Compile - Step-By-Step
Let me try a step-by-step description of what you can do in a freshly made WiX 3 project to make it compile with a default WiX GUI. You can see these changes "merged" into a complete sample in the last section of the answer, but do read this step-by-step so it makes sense.
Create a new WiX3 project. You know how to do that, I won't waste time with the details.
Set the Manufacturer attribute to your company name. Now set a new name of your choosing to the Name attribute. In this sample it is set to MinimalTester - use something else please.
Change <MediaTemplate /> to <MediaTemplate EmbedCab="yes" /> to use embedded cab files in the MSI. This way only the MSI is created and there is no additional, external CAB file.
Directly after the MediaTemplate element, add this: <UIRef Id="WixUI_Mondo" />. This will add a default WiX dialog set to your MSI so it has the basics of what is needed to be more generically useful. You can now run repair, and modify and you get a wizard for the original install along the lines of what most MSI files provide from Installshield or Advanced Installer or other professional tools. And crucially: your administrative installation will have a dialog where you can specify where files should be extracted to.
We will add our own License Agreement to the WiX setup (or else you will get an mumbling default one). Directly following <UIRef Id="WixUI_Mondo" /> add this element: <WixVariable Id="WixUILicenseRtf" Value="TestLicenseAgreement.rtf" />. Now create the file TestLicenseAgreement.rtf and place it in the same folder as your main WiX source file (quick way: in Visual Studio, right click project and "Open Folder in File Explorer", now create the RTF file with right click => New => RTF file
. And maybe open the RTF and enter some test text). Further customization of the dialogs (bitmaps and more).
The WiX dialog set is defined in a dll, we need to reference it. In your Visual Studio WiX project: Right click References => Add Reference... => Navigate to C:\Program Files (x86)\WiX Toolset v3.11\bin\. Double click WixUIExtension.dll and finally click OK.
Now add the absolute minimal component possible in WiX with an absolute path specified as source. This is to be sure you can compile the MSI. Afterwards you can make the path relative or a variable (just add this directly under the INSTALLFOLDER directory element for now):
<Component Feature="ProductFeature">
<File Source="C:\Users\someone\SourceControl\MyProject\CoreApp.exe" />
</Component>
Finally right click the WiX project in your solution and select Build. And you can quickly test run the MSI by right clicking the WiX project and clicking Open Folder in File Explorer. Now double click on bin and then Debug (or Release if you switched to a release build - not sure what "default differences" are between the two configurations). You should see your own license agreement in the second dialog in the dialog sequence.
The later WiX versions have great defaults for attributes that are almost always set to "template values" or where two attributes essentially are redundant. Just leave them out of your source and let the WiX compiler add them with default values. Much less fuss.
As an example: The above element lacks a Component Id. During compilation it defaults to the Id of the File element it contains. The File element Id in turn, is also missing and will default to the file name specified by the Source attribute (which is a mandatory attribute).
Maybe look at this answer for a longer description and a concrete example towards the bottom: Syntax for guids in WIX? See how simple your WiX source files can be once you eliminate all the redundancy and duplication of certain attributes? Less text, less bugs.
Sample Minimal WiX Source - Inline Comments
In the below sample the component has been moved into the default ComponentGroup - hence there is no need to specify what feature it belongs to (unlike above).
<?xml version="1.0" encoding="UTF-8"?>
<Wix xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!--CHANGE 0: Set Manufacturer attribute to something, you must also specify a full GUID for UpgradeCode -->
<Product Id="*" Name="MinimalTester" Language="1033" Version="1.0.0.0" Manufacturer="My Company" UpgradeCode="PUT-GUID-HERE">
<Package InstallerVersion="200" Compressed="yes" InstallScope="perMachine" />
<MajorUpgrade DowngradeErrorMessage="A newer version of [ProductName] is already installed." />
<!--Standard: <MediaTemplate />-->
<!--CHANGE #1: Enable embedded cab files, so there is only one file generated, the MSI file -->
<MediaTemplate EmbedCab="yes" />
<!--CHANGE #2: Add the following elements to link one of the default WiX GUI sequences and show the specified license agreement. The RTF file must be created and placed next to your WiX source file -->
<UIRef Id="WixUI_Mondo" />
<WixVariable Id="WixUILicenseRtf" Value="TestLicenseAgreement.rtf" />
<!--CHANGE #3: Add WiX dll reference. In Visual Studio WiX project: Right click References => Add Reference... => Navigate to C:\Program Files (x86)\WiX Toolset v3.11\bin\. Double click WixUIExtension.dll. Click OK -->
<Feature Id="ProductFeature" Title="MinimalTester" Level="1">
<ComponentGroupRef Id="ProductComponents" />
</Feature>
</Product>
<Fragment>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFilesFolder">
<Directory Id="INSTALLFOLDER" Name="MinimalTester" />
</Directory>
</Directory>
</Fragment>
<Fragment>
<ComponentGroup Id="ProductComponents" Directory="INSTALLFOLDER">
<!--CHANGE #4: Remove TODO elements, add the most basic component possible as illustrated below -->
<Component>
<File Source="C:\Users\someone\SourceControl\MyProject\CoreApp.exe" />
</Component>
</ComponentGroup>
</Fragment>
</Wix>
Try to compile and test install. Should install to C:\Program Files (x86)\MinimalTester on a normal system.
Maybe see further links for WiX tutorials here: WIX Installer not displaying the custom image of WixUI Dialog correctly.
Try this:
https://github.com/iswix-llc/iswix-tutorials
https://www.youtube.com/watch?v=nnV_OU6fk8c
Disclaimer: I'm the maintainer of IsWiX, a FOSS WiX accelerator that provides enhanced project templates (scaffolding) and graphical designers to do the majority of the WiX XML heavy lifting for you. As you can see from the video, this is easily only a few minutes of work.
I have a C# app that was initially written in VS2015 but earlier this year we upgraded to 2017. I opened the project in VS2017 months ago and kept going. There is a long story that I don't think is relevant here about some serious weirdness that happened to that app related to css and js deployment in the last 4-5 business days. Suffice it to say that I threw up my hands and created a new c#/.net framework project in VS2017 and copied the main source files and the web.config file over; re-made my models; brought in the necessary nuget packages, etc. I built the project without issue.
I am now trying to do a Web Deploy. This should be a simple thing. the "release" version of the project needs to have the relevant files transferred to an IIS dev server. I did this many, many times with VS2017 before the weirdness. It worked.
Now, with a .Net Framework project created from scratch in VS2017 Web Deploy fails with the error
The 'Connection String' argument cannot be null or empty.
This is peculiar since when I created the Deploy profile I told it not to deploy databases. It appears, however, that unchecking the "Use this connection string at runtime" boxes in the Web Deply settings is ignored. Unchecking the boxes and saving the edits then re-editing the settings shows the boxes checked. Unchecking, saving, exiting VS and re-entering has the boxes checked.
I see the connection elements in the Release.pubxml file generated
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
...
<PublishDatabaseSettings>
<Objects xmlns="">
<ObjectGroup Name="MsSQLEntities" Order="1" Enabled="False">
<Destination Path="" />
<Object Type="DbCodeFirst">
<Source Path="DBContext" DbContext="myapp.Models.MsSQLEntities, My App" Origin="Configuration" />
</Object>
</ObjectGroup>
<ObjectGroup Name="MySQLEntities" Order="2" Enabled="False">
<Destination Path="" />
<Object Type="DbCodeFirst">
<Source Path="DBContext" DbContext="myapp.Models.MySQLEntities, My App" Origin="Configuration" />
</Object>
</ObjectGroup>
</Objects>
</PublishDatabaseSettings>
</PropertyGroup>
<ItemGroup>
<MSDeployParameterValue Include="MySQLEntities-Web.config Connection String">
<UpdateDestWebConfig>False</UpdateDestWebConfig>
</MSDeployParameterValue>
<MSDeployParameterValue Include="MsSQLEntities-Web.config Connection String">
<UpdateDestWebConfig>False</UpdateDestWebConfig>
</MSDeployParameterValue>
</ItemGroup>
</Project>
I have looked at the Release.pubxml file from an earlier copy that was made of this project. It would have been made bt vs2015. Eventhough I know that I unchecked the DB connection boxes above; this file has full connection strings in it.
I have now tried copying the "old" pubxml file to the new project but nothing changes.
Oh, just noticed in the pubxml file above it talks about "DbCodeFirst". I am pretty sure this was all DB first.
Help?
EDIT
sorry, somehow duplicated a section in the original
Found the issue. Something in the way the MySQL libs set themselves up puts a lot of bogus chaff in the web.config file. All the entries mention connectionStringName="LocalMySqlServer". I commented out all those blocks and it's working again.
Also, even though web publish threw up a popup to tell me it had failed, it really hadn't. It actually published to the remote dev site. Running the app over there dumped enough error hints to find the info above.
Trying to build my project on the build server gives me the following error:
Microsoft (R) Build Engine Version 4.0.30319.1
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlTasks.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
error MSB4019: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" was not found. Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
I solved this problem a few months ago, with installing Visual Studio 2010 on the Build Server. But now I'm setup a new server from scratch, and I want to know if there any better solution to solve this issue.
To answer the title of the question (but not the question about the output you're getting):
Copying the following folder from your dev machine to your build server fixes this if it's just web applications
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications
Remove x86 according to how your build breaks. If you have other project types you will probably need to copy the entire msbuild folder.
The solution would be to install redistributable packages on build server agent. It can be accomplished multiple ways, out of which 3 are described below. Pick one that suits you best.
Use installer with UI
this is the original answer
Right now, in 2017, you can install WebApplication redists with MSBuildTools. Just go to this page that will download MSBuild 2017 Tools and while installation click Web development build tools to get these targets installed as well:
This will lead to installing missing libraries in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications by default
Use command line
disclaimer I haven't tested any of the following proposals
As #PaulHicks and #WaiHaLee suggested in comments, it can also be installed in headless mode (no ui) from CLI, that might actually be preferable way of solving the problem on remove server.
Solution A - using package manager (choco)
choco install visualstudio2017-workload-webbuildtools
Solution B - run installer in headless mode
Notice, this is the same installer that has been proposed to be used in original answer
vs_BuildTools.exe --add Microsoft.VisualStudio.Workload.WebBuildTools --passive
Building and publishing WAPs is not supported if VS is not installed. With that said, if you really do not want to install VS then you will need to copy all the files under %ProgramFiles32%\MSBuild\Microsoft\.
You will need to install the Web Deploy Tool as well. I think that is it.
UPD: as of VS2017, there is workload in Build Tools that eliminates this problem completely. See #SOReader answer.
If you'd prefer not to modify anything on build server, and you still want the project to build right out of source control, it might be a good idea to put the required binaries under source control. You'll need to modify the imports section in your project file to look like this:
<Import Project="$(SolutionDir)\BuildTargets\WebApplications\Microsoft.WebApplication.targets" />
<Import Condition="false" Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
The first line is the actual import from the new location that is relative to the solution directory. The second one is a turned-off version (Condition="false") of the original line that allows for Visual Studio to still consider your project to be a valid Web Application Project (that's the trick that VS 2010 SP1 does itself).
Don't forget to copy the C:\Program Files (x86)\Microsoft\VisualStudio\v10.0\WebApplications to BuildTargets folder under your source control.
You can also use the NuGet package MSBuild.Microsoft.VisualStudio.Web.targets, referencing them within your Visual Studio project(s), then change your references as Andriy K suggests.
Based on this post here you can simply download the Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package and the targets are installed.
This avoids the need to install Visual Studio on the build server.
I have just tried this out now, and can verify that it works:
Before:
error MSB4019: The imported project "C:\Program Files
(x86)\MSBuild\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
After the install:
[Builds correctly]
This is a far better solution than installing Visual Studio on a build server, obviously.
The latest Windows SDK, as mentioned above, in addition to the "Microsoft Visual Studio 2010 Shell (Integrated) Redistributable Package" for Microsoft.WebApplication.targets and "Microsoft Visual Studio Team System 2008 Database Edition GDR R2" for Microsoft.Data.Schema.SqlTasks.targets should alleviate the need to install Visual Studio 2010. However, installing VS 2010 maybe actually be less overall to download and less work in the end.
Add dependency through NuGet & set a Build Parameter
Goal: no changes / installs necessary to the build agents
I have taken a hybrid approach to the NuGet approach by Lloyd here, which was based off of the committing binary dependencies solution by Andrik.
The reason why is I want to be able to add new build agents without having to pre-configure them with items such as this.
On a machine with Visual Studio, Open the solution; ignore that the web project fails.
In the NuGet package manager, add MSBuild.Microsoft.VisualStudio.Web.targets, as Lloyd mentioned.
This will resolve the binaries to [solution]\packages\MSBuild.Microsoft.VisualStudio.Web.targets.nn.n.n.n\tools\VSToolsPath\
You can copy these to a references folder & commit,
Or just use them where they are at. I chose this, but I'm going to have to deal with the version number in the path later.
In Version 7, I did the following. This may not have been necessary, and based on the comments is definitely not needed now. Please see the comments below.
Next, in your TeamCity build configuration, add a build Paramenter for env.VSToolsPath and set it to the VSToolsPath folder; I used ..\packages\MSBuild.Microsoft.VisualStudio.Web.targets.11.0.2.1\tools\VSToolsPath
When building on the build/CI server, turn off the import of Microsoft.WebApplication.targets altogether by specifying /p:VSToolsPath=''. This will, essentially, make the condition of the following line false:
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
This is how it's done in TeamCity:
If you migrate Visual Studio 2012 to 2013, then open *.csproj project file with edior.
and check 'Project' tag's ToolsVersion element.
Change its value from 4.0 to 12.0
From
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" ...
To
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="12.0" ...
Or If you build with msbuild then just specify VisualStudioVersion property
msbuild /p:VisualStudioVersion=12.0
Solution Source
It seems the new version of msbuild does not ship with Microsoft.WebApplication.targets. To fix you need to update your csproj file as so:
1) Edit the web app csproj (right click). Find the section in the csproj towards the bottom concerning build tools. It should look like so.
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
2) You need to add one VSToolsPath line below the VisualStudioVersion tag so it looks like so
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<!--Add the below line to fix the project loading in VS 2017 -->
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<!--End -->
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
Reference link:
https://alastaircrabtree.com/cannot-open-vs-2015-web-project-in-vs-2017/
This is all you need. Only 103MB. Don't install everything
I have found this on MS connect:
Yes, you need to install Visual Studio
2010 on your build machine to build
database projects. Doing so does
not require an additional license of
Visual Studio.
So, this is the only option that I have for now.
Anyone coming here for Visual Studio 2017. I had the similar issue and couldn't compile the project after update to 15.6.1.
I had to install MSBulild tools but still the error was there.
I was able to fix the issue by copying the v14.0 folder from C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio to the same folder as v15.0 and that resolved all the errors.
So now my folder structure looks like below, where both folders contain the same content.
If you are using MSBuild, as in the case of a build server, what worked for me is:
Change the following:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
to:
<Import Project="$(MSBuildBinPath)\Microsoft.VisualBasic.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
My Msbuild command is: *"C:\Program Files (x86)\MSBuild\14.0\Bin\MSBuild.exe" solution.sln /p:Configuration=Debug /p:Platform="Any CPU"*
Hope this helps someone.
My solution is a mix of several answers here.
I checked the build server, and Windows7/NET4.0 SDK was already installed, so I did find the path:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets`
However, on this line:
<Import Project="$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v9.0\WebApplications\Microsoft.WebApplication.targets" />
$(MSBuildExtensionsPath) expands to C:\Program Files\MSBuild which does not have the path.
Therefore what I did was to create a symlink, using this command:
mklink /J "C:\Program Files\MSBuild\Microsoft\VisualStudio" "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio"
This way the $(MSBuildExtensionsPath) expands to a valid path, and no changes are needed in the app itself, only in the build server (perhaps one could create the symlink every build, to make sure this step is not lost and is "documented").
I fixed this by adding
/p:VCTargetsPath="C:\Program Files\MSBuild\Microsoft.Cpp\v4.0\V120"
into
Build > Build a Visual Studio project or solution using MSBuild > Command Line Arguments
I tried a bunch of solutions, but in the end this answer worked for me: https://stackoverflow.com/a/19826448/431522
It basically entails calling MSBuild from the MSBuild directory, instead of the Visual Studio directory.
I also added the MSBuild directory to my path, to make the scripts easier to code.
I was having this issue building a SQL Server project on a CI/CD pipeline. In fact, I was having it locally as well, and I did not manage to solve it.
What worked for me was using an MSBuild SDK, capable of producing a SQL Server Data-Tier Application package (.dacpac) from a set of SQL scripts, which implies creating a new project. But I wanted to keep the SQL Server project, so that I could link it to the live database through SQL Server Object Explorer on Visual Studio. I took the following steps to have this up and running:
Kept my SQL Server project with the .sql database scripts.
Created a .NET Standard 2.0 class library project, making sure that the target framework was .NET Standard 2.0, as per the guidelines in the above link.
Set the contents of the .csproj as follows:
<?xml version="1.0" encoding="utf-8"?>
<Project Sdk="MSBuild.Sdk.SqlProj/1.0.0">
<PropertyGroup>
<SqlServerVersion>Sql140</SqlServerVersion>
<TargetFramework>netstandard2.0</TargetFramework>
</PropertyGroup>
</Project>
I have chosen Sql140 as the SQL Server version because I am using SQL Server 2019. Check this answer to find out the mapping to the version you are using.
Ignore the SQL Server project on build, so that it stops breaking locally (it does build on Visual Studio, but it fails on VS Code).
Now we just have to make sure the .sql files are inside the SDK project when it is built. I achieved that with a simple powershell routine on the CI/CD pipeline that would copy the files from the SQL Server project to the SDK project:
Copy-Item -Path "Path.To.The.Database.Project\dbo\Tables\*"
-Destination (New-item -Name "dbo\Tables" -Type Directory -Path "Path.To.The.DatabaseSDK.Project\")
PS: The files have to be physically in the SDK project, either in the root or on some folder, so links to the .sdk files in the SQL Server project won't work. In theory, it should be possible to copy these files with a pre-build condition, but for some obscure reason, this was not working for me. I tried also to have the .sql files on the SDK project and link them to the SQL Server project, but that would easily break the link with the SQL Server Object Explorer, so I decided to drop this as well.
In case if you're trying to deploy a project using VSTS, then issue might be connected with checking "Hosted Windows Container" option instead of "Hosted VS2017"(or 18, etc.):
I fixed this by running the build in a docker container, specifically dotnet/framework/sdk. It includes the VS build tools.
Creating a new project and copying over the settings should probably provide the best guidance in what to do. This is what it looks like on mine
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
<Import Project="$(VSToolsPath)\WebApplications\Microsoft.WebApplication.targets" Condition="'$(VSToolsPath)' != ''" />
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
In my case, It was just a Port-Block.
After installation of MSBuild tools from Microsoft, define the MSBuild path in the environment variable, so that it can be run from any path.
Edit the .csproj file in any notepad editor such as notepad++, and comment the
Check for the following elements,
-->
Make sure you use import only once, choose whichever works.
Make sure you have the following folder exists on the drive, "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0" or whichever version is referenced by MSBuild target at "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\WebApplications\Microsoft.WebApplication.targets"
From the command prompt, run the following command, to check
C:>msbuild "C:\\DotnetCi.sln" /p:Configuration=Release /p:UseWPP_CopyWebApplication=true /p:PipelineDependsOnBuild=false
choose /p switch as appropriate, refer to enter link description here
enter image description here
I have developed a Windows service along with a setup project using Visual Studio 2008. When I do an upgrade install I get the following warning:
The following applications are using files which the installer must update. You can either close the applications and click "Try Again", or click "Continue" so that the installer continues the installation, and replaces these files when your system restarts.
I would like to stop the Windows service during the upgrade install. I have tried creating a custom action and overriding the OnBeforeInstall methoc, however this gets called too late after the warning pop-up message has already occurred.
Is there any way to accomplish this as part of the msi installer. I would prefer to not have to do this as a separate task prior to executing the msi installer.
Update:
Based on further research I have found that the MSI database does support this, however the built-in Visual Studio installer (setup) projects do not provide a means to do this. One must either tweak the MSI database, or go with WiX or a commercial installer.
If you want to go down the route of editing the MSI ServiceControl table, this following VBS script worked for me:
Dim installer, database, view, result
Set installer = CreateObject("WindowsInstaller.Installer")
Set database = installer.OpenDatabase ("Installer.msi", 1)
Set view = database.OpenView("INSERT INTO ServiceControl (ServiceControl,Name,Event,Arguments,Wait,Component_) VALUES ('ServiceName','ServiceName',170,null,null,'C__751A71A3822A287367770DB29839A759')")
view.Execute
database.Commit
Set database = nothing
Look at: Upgrade a Windows Service without Uninstalling
Its already been built in to the MSI / Windows Installer ... the only problem is that the .NET installer classes doesn't use the MSI "Service Installation" features. What is actually happening is that the MSI is trying to install files and run a custom command using the files just copied (that is all Visual Studio is putting in the MSI).
To solve it you can edit the MSI with ORCA and add the following row to the ServiceControl table:
1 ServiceName 170 1 C__489628C5CC1144CB47F43E8BE7F3F31D
The Component ID you can lookup from the FILES table ... I just chose the main EXE file's Component ID. The 170 is a bitmap that tells the Windows Installer to stop and delete the service when Installing and Uninstalling.
This will clear the road for the .NET installers to add service and you can use the ServiceController to start the service after it's been installed via custom command.
In WIX, I was able to get the service to shutdown before upgrade and uninstall by adding a "ServiceControl" element to stop the service on install. This seems to do the job, but everything related to MSI is close to black magic, so I am certainly open to any comments. Below is what my service component is defined as:
<Component Id="ServicePrima" Guid="{d0847344-8632-4326-986c-78f4e02a41bb}">
<ServiceControl Id="ServicePrima_BeforeInstall" Name="ServicePrima" Stop="install" Wait="yes"/>
<File Name="PrimaPro.ServicePrima.Check.cmd" />
<File Name="PrimaPro.ServicePrima.exe" Id="ServicePrimaExe" KeyPath="yes" />
<File Name="PrimaPro.ServicePrima.exe.config" />
<File Name="PrimaPro.ServicePrima.Install.cmd" />
<File Name="PrimaPro.ServicePrima.pdb" />
<File Name="PrimaPro.ServicePrima.Restart.cmd" />
<File Name="PrimaPro.ServicePrima.SignalRestart.cmd" />
<File Name="PrimaPro.ServicePrima.Uninstall.cmd" />
<File Name="PrimaPro.ServicePrima.xml" />
<ServiceInstall Id="ServicePrima_Install" Name="ServicePrima" DisplayName="PrimaPro - ServicePrima"
Type="ownProcess" Start="auto" Interactive="no" ErrorControl="normal"
Description="Manages the database synchronization and configuration management of the PrimaPro System and databases on a machine.">
</ServiceInstall>
<!-- Do not need to start service here (i.e. attribute Start="install"), the service will be started by "RestartServices" custom action. -->
<ServiceControl Id="ServicePrima_AfterInstall" Name="ServicePrima" Stop="uninstall" Remove="uninstall" Wait="yes"/>
</Component>