I'm using a Visual Studio MSIX packaging project to create an installer on a network share for an internal application.
One problem is that it's creating a directory with "_Test" at the end.
Why is it doing that and how do I get rid of it? I just want "MyApp.MSIX_0.0.1.0", or ideally, "MyApp.0.0.1.0".
Directory of I:\
08/14/2020 09:44 AM <DIR> .
08/14/2020 09:44 AM <DIR> ..
08/14/2020 09:44 AM 21,312 index.html
08/14/2020 09:23 AM 601 MyApp.MSIX.appinstaller
08/14/2020 09:37 AM <DIR> MyApp.MSIX_0.0.1.0_Test
2 File(s) 21,913 bytes
3 Dir(s) 62,444,621,824 bytes free
I've been scouring the documentation, but I can't find anything about the directories it creates or the index.html file it generates. I'd like to customize all that, add release notes, etc.
This is a WPF app, if that makes any difference.
I am just placing here a copy of the original answer from MSFT:
The output directory of the packages is defined in the Microsoft.AppxPackage.Targets file at C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage (depending on your version of Visual Studio).
If you want to remove the "_Test" suffix you can modify the lines defining the output directory. In my file it was around line 3190 - 3196:
To modify the output html file, modify the index.template.html file in the "Landing" subdirectory - C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Microsoft\VisualStudio\v16.0\AppxPackage\Landing (depending on VS version).
If you are using Azure Pipelines to deploy, you can add parameters to the MSBuild task to do this. For example:
Hardcoded:
task: MSBuild#1
displayName: MSBuild
inputs:
solution: '**/*.sln'
platform: 'x64'
configuration: 'Release'
msbuildArguments: '/p:OutDir=$(Build.BinariesDirectory)/
/p:AppxPackageTestDir="$(Build.BinariesDirectory)/MyApp.Installer/AppPackages/MyApp_1.0.0/"'
or using pipeline variables:
msbuildArguments:
/p:OutDir=$(Build.BinariesDirectory)/
/p:AppxPackageTestDir="$(Build.BinariesDirectory)/MyApp.Installer/AppPackages/$(packageName)_$(newVersion)/"
This gives a folder called "MyApp_1.0.0"
instead of the confusing "MyApp_1.0.0_Test".
And the Uri property inside the .appinstaller file will correctly point to this folder.
For 2022 Professional, the file is: C:\Program Files\Microsoft Visual Studio\2022\Professional\Msbuild\Microsoft\VisualStudio\v17.0\AppxPackage\Microsoft.AppxPackage.Targets
Related
I have a project in Visual Studio and want all files generated during build under the build\ subdirectory.
I set all output options I could find but there is still a Debug\ folder created with the files: projectname.dll.recipe and subfolder projectname.xxxx.tlog which contains .tlog and .lastbuildstate files.
I know the .tlog files are from the MSBuild File Tracker, know idea what the .dll.recipe is.
How can I set the output directory for those files to $(OutDir)?
You can try the following steps:
Function 1
Open your project in VS IDE and then right-click on the project Properties-->Configuration Properties-->General--> change Intermediate Directory to ..\$(Configuration).
Then, rebuild your project to get what you want.
Function 2
1) add a file called Directory.Build.props in your solution folder like this:
2) add these content in the Directory.Build.props:
<Project>
<PropertyGroup>
<IntDir>..\$(Configuration)\</IntDir>
</PropertyGroup>
</Project>
3) close VS Instance, delete any Debug folder in your solution folder.
Then restart VS(enable the function of the Directory.Build.props) to open your solution to build again and the files will be under the $(OutDir) path.
In Visual Studio, when we publish to a folder, that folder contains exactly what we need to deploy.
In Azure Pipeline, the Build Solution task produces a a bunch of (to us) unnecessary files plus a zip file (nice!). The zip contains the files we need, but buried in an crazy deep folder path:
\Content\D_C\a\1\s\src\MyProject\obj\Release\Package\PackageTmp\our-files.dll
What we would prefer is:
\our-files.dll
It also modifies connectionStrings in the web.config to support the deploy script it ships with. We don't need that script and that modification is a pain (which we disabled by adding<AutoParameterizationWebConfigConnectionStrings>false</...> to the .csproj file - yuck!)` .
We tried fussing with the parameters in the Build Solution step:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\"
Changing DeployOnBuild to false caused the $(build.artifactsstagingdirectory) to be empty (causing the next step to deploy nothing)
Changing WebPublishMethod to FileSystem made no difference (try finding documentation on the allowed values!)
Changing PackageAsSingleFile to false did what one would expect - no zip, but the contents were still buried in that deep folder structure.
Our downstream script could open the manifest file, xpath out the deep path baked into the zip (does the path always start with d_C?), unzip and grab the contents from there - but what a pain and how unnecessary.
Is there a way to publish just a nice clean build - a zip with contents that directly unpacks to the same files as a plain-jane Publish from Visual Studio does?
In the Visual Studio Build step change "MSBuild Arguments" to
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)\\" /p:UseWPP_CopyWebApplication=true /p:OutDir="$(build.artifactstagingdirectory)"
The key thing is /p:OutDir="$(build.artifactstagingdirectory)" resolves the directory issue and /p:UseWPP_CopyWebApplication=true removes web.config.release and web.config.debug
Then update Publish Build Artifacts step "Path to publish" to
$(build.artifactstagingdirectory)\_PublishedWebsites
I created a new UWP MSTest Project and I added a reference to my main application. When I build the solution, get the an error:
Payload contains two or more files with the same destination path
Along with the conflicting files. I checked the copy to local for the files and they are set to Do not copy. Here's a sample of the error messages:
Severity Code Description Project File Line Suppression State
Error Payload contains two or more files with the same destination
path 'Assets\Square44x44Logo.targetsize-24_altform-unplated.png'.
Source files:
C:\Users\joe.nuget\packages\newtonsoft.json\11.0.1-beta1\lib\netstandard2.0\Newtonsoft.Json.dll
C:\Program Files (x86)\Microsoft SDKs\Windows
Kits\10\ExtensionSDKs\TestPlatform.Universal\15.5\Redist\CommonConfiguration\neutral\Newtonsoft.Json.dll App.Test C:\Program
Files (x86)\Microsoft Visual
Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets 1747
Error Payload contains two or more files with the same destination
path 'Assets\Wide310x150Logo.scale-200.png'. Source files:
E:\App.Test\Assets\Wide310x150Logo.scale-200.png
E:\App\Assets\Wide310x150Logo.scale-200.png App.Test C:\Program Files
(x86)\Microsoft Visual
Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\AppxPackage\Microsoft.AppXPackage.Targets 1747
This happens when the content file names are the same for the app itself and the test project. Even though you set them to Do not copy, they are still conflicting during the intermediate step of building the test project.
The simplest solution is to rename or delete the Asset PNGs inside the Test Project so that they do not conflict with your app itself.
Newtonsoft.Json
Problem with Newtonsoft.Json is a known issue that has been reported to the Visual Studio team and the fix is now pending release.
The only workaround mentioned is the following by Morten Nielsen:
As a workaround and if you can live with the v9 version the test
project ships with, you can add a direct assembly reference to the
Json.net lib that they use, instead of using the nuget reference.
I have a solution, which consists out of 2 projects: regular class library for .NET 4.5 + website (not web application) project.
When I build this solution with Visual Studio - all referenced assemblies from Nuget packages and local references are copied to bin folder of website project.
If I try to build solution with MsBuild - bin folder of website project does not receive any assemblies.
Website project is not selected to be built in VS configuration (which is reported by message in both cases)
Edit - here is additional explanation.
When I clone a project from git - bin folder of website contains only 4 assemblies already checked in:
If I will run msbuild command with /t:Build or /t:Rebuild and /p:Configuration=Release;Platform="Any CPU" - I'll receive just an output of postbuild event in my other project, included in solution:
However, if I execute build from VS (Ctrl + Shift + b) in Release/Debug config - bin have all required assemblies for running web application.
Edit 2: Link to example solution - https://github.com/akuryan/csharp-website-test
When one builds it with msbuild TestApp.sln /t:Rebuild /p:Configuration=Release;Platform="Any CPU" - this results in only Test.Core.* and LetsEncrypt.Umbraco.dll (initially checked in) found at ~\Test.Web\bin\ (where Test.Web is website project). If one builds TestApp.sln with VisualStudion 2015 (I suppose, 2013 and 2017 will be the same) - ~\Test.Web\bin\ gets whole amount of assemblies.
Different results with MsBuild and Visual Studio
That because the all dll.refresh file in bin folder alongside the binary file are ignored by .gitignore.
Since Web Site projects do not have any project file (.csproj) to put the assembly references, the *.dll.refresh files are used by MSBuild to understand the assembly references. The contents of the file is the relative path to the .dll via the packages folder for the solution. When you ignore all those .dll.refresh by .gitignore, MSBuild could not understand how to handle the dll files.
To test this, I created a website project, add a nuget package to it, then delete the dll files but keep the .dll.refresh files in the bin folder. Build the website project by MSBuild command line:
msbuild.exe TestWebsite.sln /t:Rebuild
After this command complete, the dll files are copy to the bin folder.
So build and package restore to work it looks like you need to keep the .dll.refresh files in the bin folder. You can remove the other binaries from your version control system.
Note: If you want to get those .dll.refresh back, you can use the command line in the Package Manager Console:
update-package -reinstall
Hope this helps.
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?