How do i create a windows store app package using command prompt?
I have tried devenv, but it just builds the project, it doesn't creates any app packages.
I tried using msbuild, but i have dependencies from other projects which msbuild doesn't recognizes and hence not building.
I tried using MakeAppx.exe, but it is too cumbersome. Can anyone suggest a solution.
Use msbuild with your solution file.
This is how we do it:
msbuild yoursolution.sln /t:Rebuild /p:Configuration=Release;OutDir=..\Release\;Platform="x86"
Your command line parameters will probably have to be tweaked and you will need to do this three times, once for each platform (ARM, x86, x64).
Related
I have the following as part of a "Deploy" project which I run manually from a batch file using msbuild.exe (VS2017).
<Target Name="ZipRelease"
DependsOnTargets="getversion;gettime">
<MakeDir Directories="$(ReleaseDir)" Condition="!Exists('$(ReleaseDir)')" />
<ZipDirectory Condition="Exists('$(BuildDir)')"
SourceDirectory="$(BuildDir)"
DestinationFile="$(ReleaseDir)\$(MODNAME)-$(DLLVersion)_$(CurrentDate).zip" />
</Target>
On one PC I use the Community Edition of VS2017. I may also have installed VS2019 on that machine (no way to check for a couple of weeks). Crucially the batch file forces the use of VS2017. On another PC I have VS2017 Professional.
On the PC using the Community Edition, this task creates correct zip files which use forward-slashes as the path separator. On the PC using VS2017Pro, the task creates zip files with back-slashes which is obviously against the spec and causes lots of problems (the resulting ZIP is deployed on Linux as well as Windows).
This thread indicates DotNet 4.6.1 or later fixes the path separator used when creating ZIP files. I specify ToolsVersion="15.8" as part of the Project configuration (minimum version for the ZipDirectory task), but how do I force the DotNet version for an MSBuild Task?
I've tried uninstalling all earlier versions of Dotnet SDK/target framework from the PC to no avail.
There's also an override documented (Switch.System.IO.Compression.ZipFile.UseBackslash), but that only applies to applications, not MSBuild Tasks.
As seems usual with MS stuff, there's inconsistencies everywhere and my Google skills are insufficient to find an answer so grateful for anybody being able to point me in the right direction.
Installing VS2019 fixes it.
It seems my script automatically configures itself to use the newest version of Visual Studio instead of forcing itself to VS2017 as I had originally stated.
Even though all DotNet version numbers as reported by the build script for its runtime framework are still the same, something is obviously different between running in a VS2017 vs VS2019 environment.
It would be very very nice to figure out exactly what and whether it's possible to force the VS2017 intall to use that as well..
Try to use
<ZipDirectory Condition="Exists('$(BuildDir)')"
SourceDirectory="$(BuildDir)"
DestinationFile="$([System.String]::Copy($(ReleaseDir)\$(MODNAME)-$(DLLVersion)_$(CurrentDate).zip).Replace('\', '/'))" />
Actually, all my agents are using back-slashes for path. And windows always uses back-slashes for path, so I wonder if you have made some changes to your windows or VS IDE to use forward-slashes for that PC.
Linux uses forward-slashes but Windows do not use that by default.
You can open the folder of the C disk to check whether the path uses forward-slashes. And make sure whether you have run some cmd commands to use that.
Open VS IDE, compare with the two versions from the two PCs, open Extensions-->Manage Extensions-->Installed to check whether you have installed some extensions to cause that.
We have a number of .NET Framework projects with a "nuget pack MyProject.csproj" command in the post-build step. We have been using VS2010 (:O I know) until now, and it has been happily spitting out nupkg files.
We recently updated our build tools to the 2019 version (running the new version of varsall.bat before calling msbuild), and the "nuget pack" command now fails:
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project has been built.
What I've tried:
Adding a "nuget spec" step before packing
Upgrading the nuget CLI executable to the latest version
Updating from packages.config to PackageReferences
This allows you to use MSBuild -t:pack. However, two issues:
When running this in the post-build step on my machine, it starts dozens of cmd & MSBuild processes and pegs my CPU.
Our developers are stuck on VS2017 for now, but the 2017 build tools are no longer available for our build server (so we use 2019). The 2017 & 2019 installs put MSBuild in different locations. We could set path variables for all the machines, but that seems brittle.
I'm playing with upgrading one of the projects to the new csproj format, but it is rather involved. Upgrading all of our projects will be an effort all its own, and I'm still exploring the ramifications.
Is there something simple I'm missing which will allow this to work without large modifications?
Error NU5012: Unable to find 'MyProject.dll'. Make sure the project
has been built.
This message indicates that the nuget.exe can't find the output assembly. So you must make sure the assembly is created successfully.
And one point you need to take care, normally we use command like nuget pack foo.csproj -Properties Configuration=Release to pack the assembly built in release mode. If you use command like nuget pack xx.csproj in post-build-event, no matter which configuration you use msbuild to build the project, nuget will always try to find the assembly in ProjectDir/bin/debug.
So when you deploy the project to remote server without bin and obj folders, if you try to use command like msbuild xx.csproj /p:Configuration=Release, the build is in release mode while nuget.exe will search the bin\debug instead of expected bin\release. You should check if you're in same situation.
Why does NuGet pack break with VS2019 build tools?
This issue is not about the build tools package. Since the error message you got came from nuget. Msbuild just help call the nuget.exe, and the cause of the issue is nuget.exe can't find the needed assembly by one specific path. Please check if the path in the error message is right, and then check if the assembly is in that path.
I also ran into the same issue during our TFS upgrade to Azure Devops. The new Nuget task doesn't have the switch for -Build. The fields in the Nuget task screen for Pack also doesn't allow you to add this switch, that's why it's complaining about not finding the dll or the output of the build. I modified the nugetpack.js file on the agent's task folder to test the theory and now the pack options build successfully.
This is the line I added to the js file (towards the bottom of the page):
nugetTool.arg("-Build");
what would be nice is to have this option represented as check box to cover if there is use case to call Nuget pack without -Build switch
I have a C# solution with VS 2017, containing an app project, a desktop extension project, and a packaging project. As I mentioned in the answer of this question, I finally get msbuild to create a single bundle with both x86 and x64 for me. However, after I tried to install from that bundle, I found that msbuild actually picked up the wrong package.appxmanifest because they have different version numbers.
So... I have two package.appxmanifest, one in packaging project, and one in my main app project. When I build from the wizard in VS 2017, the one in packaging project will be used, which is correct. When I use msbuild to build with just one platform, it will pick the right one as well, like this:
msbuild .\MyApp.sln /p:Configuration=Release /p:Platform=x86
Only when I use msbuild to build two platforms together, it will use the one in my main app project:
msbuild .\MyApp.sln /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64" /p:UapAppxPackageBuildMode=StoreUpload
I also tried to build the packaging project instead of the solution, but because our desktop extension project is only x86, I will get errors about configurations when building x64.
Questions:
Does anyone know why this is happening?
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the platform, which platform is used to build?
Should I add <AppxBundle>Always</AppxBundle> or <AppxBundle>Never</AppxBundle> to the packaging project?
Does anyone know why this is happening?
That because you have two Package.appxmanifest files with same ID in the solution. When you create the App Bundle with .sln, MSBuild/Visual Studio could not to know clearly which Package.appxmanifest should be use.
I am also very confused about how to build multi-platform using AppxBundlePlatforms in the command line. Since I cannot specify the
platform, which platform is used to build?
Not sure the reason why you can not specify the platform. To resolve this issue, you can try yo build the project file .csproj instead of the solution file. For example, when you build the app project, you can use the command line:
msbuild .\MyApp.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86|x64"
And then build the packaging project:
msbuild .\YouPackaging.csproj /p:Configuration=Release /p:AppxBundlePlatforms="x86"
Should I add Always or
Never to the packaging project?
If you build the project, no need to add those two properties to the project file, those two properties are used to the solution level and you have a project that you do not want to add to the bundle:
because at the solution level, it’s not clear which app should appear
in the bundle. To resolve this issue, open each project file and add
the following properties at the end of the first
element
Hope this helps.
I have been trying to achieve ClickOnce deployment using MSBuild scripts, but I could not find any resource on how to copy the files after generating the manifests.
Since we need to script baby steps in case of mannual deployment, which Visual Studio does for us if we use the wizard, I'm not able to do it, since I'm new to both MSBuild and ClickOnce.
Is there a resource where I can find detailed information on how to script the entire ClickOnce deployment for multiple environments, increment version number using TeamCity's BUILD_NUMBER and sign the assemblies?
All that you see Visual Studio doing is done by MSBuild (except creating/updating the "publish.html"). This is true for any environment, if you meant configuration. To publish using MSBuild, all I do is execute the following at Command Line:
%SystemRoot%\Microsoft.Net\Framework\v3.5\msbuild <myProjectName> /p:Configuration=Debug; /t:publish
This gives me a Development environment Build (we use the default Debug configuration for Dev). For QA I just replace the "Debug" part in the above command to "Release".
I have a Visual Studio solution file (.sln), with several projects (VB.NET and C#, .vbproj, and .csproj files, respectively), and I have a Windows application, and I use ClickOnce to publish it.
Now, I need automate the Publish option using MSBuild or another good solution (cmd, VBScript, or BAT scripts).
How can I do it?
Well, ClickOnce uses MSBuild to publish itself. Therefore I would recomment to use MSBuild for your build-automation. See the reference on MSDN.
The first step is easy. You just run MSBUild with 'Publish'-target from the console. The settings made in Visual Studio are applied.
However, there are some tricky bits. For example, when you run it from the command line, the version number isn't increased. In my project I've solved this by passing the version-number from the build script.
Another tricky-part is when you want to run the build script on your build-server without Visual Studio installed. There you might have to copy some to make it work.