ClickOnce : deploy files to different location - visual-studio

Using ClickOnce, is it possible to include a file (resource, dll, image, whatever) to be copied to a different location and NOT the app folder?
What I am trying to achieve exactly is to install Microsoft.Web.Publishing.Tasks.dll + Microsoft.Web.XmlTransform.dll and their .targets to C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web so those msbuild tasks can be used on workstations that do not have Visual Studio installed.
It was so easy using a Setup Project before VS 2013!!
I repeat: I do NOT want those files to be installed in the app folder (so please don't tell me to set the option Copy to Output = Always" on project files).
Thanks.

No. You can't do it with ClickOnce.
Either deploy the files and write code to copy files when your app starts. Or use some other deployment option, like msi.

Related

Azure pipeline: msbuild does not copy one DLL in _PublishedWebsites

I have a strange behavior with msbuild on my Azure Pipeline.
I'm using Azure Pipeline with Self-hosted Windows agents.
Configuration:
My Visual Studio .sln contains two C# projects:
WebService (Rest API)
Business layer
In addition, the Business layer has dependencies on 2 others projects.
Kernel.DataModel
Kernel.DataAccess
The Kernel.DataAcess layer is using the NuGet package "Microsoft.SqlServer.Types" (14.0.314.76)
The Reference "Microsoft.SqlServer.Types" in the project Kernel.DataAccess has "Copy Local = True". Therefore the DLL file should be copied in the output (release) directory.
The problem:
When I run the Azure Build pipeline, the file "Microsoft.SqlServer.Types.dll" is not copied in the "_PublishedWebsites" directory.
To convince myself, I decided to run the same Pipeline on another build machine by changing the Agent Pool. At my surprise the DLL was present in the "_PublishedWebsites" on the second build machine.
Furthermore, I decided to manually run the msbuild command on my local computer and the the DLL was also present in the "_PublishedWebsites...\bin" on my local machine.
Log files:
I also looked at log files on the Build machines and on my local computer.
First build machine -> The DLL file is simply not copied !
Second build machine -> The DLL file is copied from this location.
Copying file from "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\Microsoft.SqlServer.Types.dll" to "F:\AgentLatestBuild\A1\_work\28\b\_PublishedWebsites\ApiProject\bin\Microsoft.SqlServer.Types.dll".
Local machine ->
_CopyFilesMarkedCopyLocal:
Copying file from "C:\TFS\Repos\Src\Project\**packages**\Microsoft.SqlServer.Types.14.0.314.76\lib\net40\Microsoft.SqlServer.Types.dll" to "E:\tfs\build\Microsoft.SqlServer.Types.dll".
Copying file from "E:\tfs\build\Microsoft.SqlServer.Types.dll" to "E:\tfs\build\_PublishedWebsites\ApiProject\bin\Microsoft.SqlServer.Types.dll".
As you can see:
On the second build machine, msbuild is not using the NuGet packages folder but it's using "C:\Program Files (x86)\Microsoft SQL Server\140\SDK\Assemblies\Microsoft.SqlServer.Types.dll"
On my local machine, the DLL is copied from the NuGet packages folder.
Here are my questions:
How msbuild.exe is selecting the source/location of the DLL ?
Is there a way to force msbuild to first use the NuGet packages instead of any others folders ?
I think msbuild should first look in the NuGet packages folder and if the DLL is not found, then it should try to find it from somewhere else. (C:\Program Files (x86), GAC, etc..)
Finally, do you have any idea why the "Microsoft.SqlServer.Types.dll" is not copied at all on the first build machine. The DLL is present in at least three locations. (ie: NuGet packages folder, C:\Program files\ and it is also in the GAC).
It looks like msbuild is lost in the dependency tracking and can't find the file or it won't copy it for some other reasons.
Thanks for your help.
Is it possible that your *.csproj is targetting the wrong HintPath?
Could you check if you have something like this:
<Reference Include="Microsoft.SqlServer.Types">
<HintPath>..\packages\Microsoft.SqlServer.Types.YOURVERSION\lib\net40\Microsoft.SqlServer.Types.dll</HintPath>
</Reference>
thanks

TFS 2015 Visual Studio Build - Package .zip not being created

I'm trying to build my solution and package up the web app into a web deploy (.zip) package to be deployed.
I've added the Visual Studio Build step with the following MSBuild Arguments:
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)\"
And I've set up the Copy and Publish Build Artifacts step to copy all .zip files to the drop folder.
The build completes successfully but nothing is copied to the drop folder because there are no .zip packages that get created.
So when I look on the TFS server, the only thing in the 'a' folder is an empty 'drop' folder. And in the 's' folder is the solution directory with a PrecompiledWeb folder in it. Not sure what that is but it doesn't look like the deployment package (and it's not a .zip).
Any ideas?
I have tried the same on VS2015 MVC web application using VSTS and TFS 2015.2.1 both. I had to do a slight change to the Build arguments in Visual Studio build. That is removing the trailing "\" in /p:PackageLocation="$(build.artifactstagingdirectory)\".
Here is the argument I passed to Visual studio build step
/p:DeployOnBuild=True /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:PackageLocation="$(build.artifactstagingdirectory)"
Then I used Copy and Published Build Artifacts (Deprecated in VSTS you should use Copy task and Publish task instead of this task) as shown below
This gives me output as below.
First suggest you manually remote in the build agent and build the project through MSBuild command line with arguments to see if the project builds properly.
This will narrow down the issue is related to the environment on your build agent or your build definition.
You should directly use /p:PackageLocation=$(build.stagingDirectory
Besides since you have multiple assemblies that are referenced in the web app. Please also double check dependencies that are building in the correct order or referenced correctly.
Make sure the ASP.NET development workload of Visual Studio is installed.
If DeployOnBuild is having no effect, you may need to install the ASP.NET Development "workload" with the VS setup tool.
There are specific .targets files that, if they don't exist, cause these parameters to be silently ignored. Installing this adds those .targets and the parameters become active, allowing the .zip to be created.
For me (VS 2017) the relevant target file (or one of them, anyway) that was missing but is needed is:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\Web\Microsoft.Web.Publishing.targets
If it is missing, you'll need to install as above, and if it is there, then you have a different problem. ;)

Why does Visual Studio publish packages.config too?

When I use the option Publish... selecting as target the file system in Visual Studio 2015 it compiles the code, do the XML transformation in the Web.config files and copy the files to the folder I specified.
It does not copy any *.cs file as expected since it is compiled.
Something that I don't understand is why it publishes the Nuget Config file (packages.config), after all, the files needed are already in the bin folder.
I found this question that says how to avoid but not the reason they decided this file would be usable on the server.
Can I stop VS from publishing packages.config?
Anyone know why packages.config end up in the publish folder?

Setup project: Using dynamic path for adding a file

Summary
Does SourcePath property of a file that is added to a setup project support variables? If yes, How can I ask it to pick the file from the folder corresponding to the current build configuration?
Detail
I'm deploying my VSTO add-in using MSI installer, which requires me to include MyAddin.vsto and MyAddin.dll.manifest files to the application folder. I include them manually using Add File command. The problem however is that if I change build configuration from Debug to Release and build my installer, it will still pick those two files from the Debug folder (becuz their paths are hard-coded in the setup project), potentially bundling an old version of the files in the installer. Therefore I want to use some macro/variable that would evaluate to the current build configuration.
The setup project file (.vdproj) adds files like this:
"SourcePath" = "8:..\\MyAddin\\obj\\Release\\MyAddin.vsto"
The path is relative, but the build configuration is hard-coded. I'm looking forward to something like:
"SourcePath" = "8:..\\MyAddin\\obj\\[$BUILD_CONFIG]\\MyAddin.vsto"
I'm using VS2015 community and .NET Framework 4.5.

Microsoft visual studio 2008 setup project

I have a bunch of files and need to build MSI file /setup.exe file that put them on specific folder and run one file of them that install a win32 service is that possible with micorosoft visual studio 2008 setp project ?
suppossing i have the following files:
file1,
file2
file3
file4
I need to put file1,file,file3 under c:\documents and setting\all users\my directory
and run file4 which install a win32 service while running the setup or the msi is that possilbe ?
Yes, that's all possible. Create a new deployment project and in the File View add the files from your project in the correct places. You may need to mark your files as Content = True in the file properties (from the solution explorer) then I think they'll appear in the dropdown in the file view.
For a windows service, the executable needs to be able to install itself as a service from the command line anyway, so installing it from the MSI is easy as you just need a custom step to call your .exe.
Yes. You can do this with a standard Setup Project. To add custom files and folders, check this link: http://msdn.microsoft.com/en-us/library/x56s4w8x.aspx
For the base "All Users" folder, you will need to specify a Special Folder, specifically the CommonAppDataFolder.
Specifying how to install a Windows Service involves using a special component. I'm not too happy with it, I much prefer Wix.

Resources