I have an issue updating my UWP app on Windows store. The issue is on the level of Visual studio (for windows). The description of the issue is the following:
Error info: error 80080204: The package with file name "MyApp_VersionNumber_x64.msix" and package full name "PackageName_VersionNumber_x64__Suffix" is not valid in the bundle because it has a different package family name than other packages in the bundle. The expected publisher is CN=PublisherName. AppName Prefix_Path\AppName\MakeAppx
The context is the following:
I update the app source code, then I associated the app in the store with the one updated.
In the windows related to the Application packages creation:
a. I choosed the distribute the application in windows store
b. Next, I choosed to always generate the application bath. (When I choose not to generate, it is impossible to publish the update because appxbundle is missing)
c. I selected the build x86, x64 and ARM like I did before
d. Finally I launch the creation to get the error above.
I followed multiple possible answer but nothing works.
Can someone helps me to overcome this issue?
Regards.
I had the same problem, the fix is a bit annoying, but for me it worked:
Close Visual Studio, go into your fileexplorer and open up the Folder with your project. Inside it you should find the "projectname.csproj" file. Open it up in your favorite texteditor and now follow the steps below:
1: Look for this line and also make sure it is the line with 'Release' and not 'Debug' in it:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
2: Inside the PropertyGroup tags you will find this line:
The value can either be true or false. If it is false, change it to true
<UseDotNetNativeToolchain>true</UseDotNetNativeToolchain>
Now repeate these steps for all four Release configurations and ONLY Release not Debug:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x86'">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|ARM'">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|ARM64'">
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release|x64'">
After this, save the file and reopen Visual Studio. It now should create the package.
Related
I want to create a configuration for a Visual Studio projectfrom command line in order to automate my release process. Typically you would go into Visual Studio, create a new configuration, select in the dropdown menu which build to copy from (in my case, this would be Release) and select the platforms. I want to do the same from command line.
I have tried the following:
MSBuild <mysolution>.sln -p:Configuration=<newconfigname>
But I get MSB4126 error, telling me that the configuration is not valid. I have also read the documentation on MSBuild, but it does not say anything about this. I am not even sure that this can be achieved using MSBuild. I am using Wix Installer in order to compile a .msi, and that works flawlessly, but it's building the Release configuration, instead of the one I want to build (custom release).
Can anyone shed some light on this issue?
I solved it by modifying some files.
You need to modify your .sln file to add your release type:
NewRelease|Any CPU = NewRelease|Any CPU
NewRelease|ARM = NewRelease|ARM
NewRelease|x64 = NewRelease|x64
NewRelease|x86 = NewRelease|x86
If you have submodules, add them as well. Create a new configuration in Visual Studio if you have doubts of what you need to add, and copy-paste from the configuration you created with Visual Studio, changing just the name of the configuration where needed.
You need to modify your .csproj file of the main project (not the WixInstaller one), for example:
<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'NewRelease|AnyCPU'">
<OutputPath>bin\NewRelease\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<Optimize>true</Optimize>
<DebugType>pdbonly</DebugType>
<PlatformTarget>AnyCPU</PlatformTarget>
<ErrorReport>prompt</ErrorReport>
<CodeAnalysisRuleSet>MinimumRecommendedRules.ruleset</CodeAnalysisRuleSet>
<Prefer32Bit>true</Prefer32Bit>
</PropertyGroup>
And, then again, if you have submodules, you have to modify every .csproj file to include your new release (copy from the other releases).
Finally, compile it with:
MSBuild <yourmainproject>.csproj -p:Configuration=NewRelease.
I'm writing an add-in for Outlook using the new framework. The manifest in the project template uses ~remoteAppUrl to represent the location of the web files. It works great during development, but to publish to the Office Store I need the production URL there. If I save the production URL to the manifest, the production server gets used during debugging, and so local changes don't show up.
The documentation mentions Visual Studio filling in this value during debugging:
Next, Visual Studio does the following:
1. Modifies the SourceLocation element of the XML manifest file by replacing the ~remoteAppUrl token with the fully qualified address of the start page (for example, http://localhost/MyAgave.html).
Is there a built-in way to have Visual Studio fill in the production URL at the appropriate time (before/during Office Store submittal), and not break debugging?
Yes, there is a built-in way to have Visual Studio replace the ~remoteAppUrl symbolic reference token by the target URL of your choice.
From Visual Studio, access the "Publish..." option of the add-in
project, then click on the "Package the add-in" button
You can then enter the URL in the modal dialog that pops up
A build is then triggered that will inject the URL in the produced Manifest XML file
A Windows Explorer window will conveniently open to show the
produced file.
The following ways are not built-in but may be useful as well.
If you want this in an automated build, you need to specify values for the build parameters IsPackaging (True) and RemoteAppUrl.
If you want this in the standard Visual Studio Build, given that Visual Studio does not provide an easy way to specify Build parameters (see How to emulate /p msbuild parameter in Visual Studio build?) you will need to edit your project file to set the values of the same build parameters.
For instance like this:
...
<PropertyGroup>
<Configuration Condition=" '$(Configuration)' == '' ">Debug</Configuration>
...
<IsPackaging>True</IsPackaging>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
...
<RemoteAppUrl>https://localhost:44300</RemoteAppUrl>
</PropertyGroup>
...
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
...
<RemoteAppUrl>https://your.own.url</RemoteAppUrl>
</PropertyGroup>
...
Edit:
Visual Studio will not fill in the production URL, however you can copy your current manifest and replace the ~remoteAppUrl with your appropriate host manually, thus giving you a production and debug version of your add-in.
Original for posterity
~remoteAppUrl is a placeholder for wherever your files are hosted. For instance, if you have uploaded your add-in to an Azure Web App, your remote app url would be something along the lines of myWebApp.azurewebsites.net
I would like to bring the light on where the value comes from to replace the ~remoteAppUrl parameter. Add-in .csproj file contains the reference to the WebApp project:
<ItemGroup>
<ProjectReference Include="..\OutlookWebAddIn1Web\OutlookWebAddIn1Web.csproj">
<Project>{57AC33A8-A364-4084-B41F-319C5DBB9FB4}</Project>
<Name>OutlookWebAddIn1Web</Name>
<Private>True</Private>
<RoleType>Web</RoleType>
<OutputItemType>SharePointWebProjectOutput</OutputItemType>
<RoleName>OutlookWebAddIn1Web</RoleName>
<ReferenceOutputAssembly>False</ReferenceOutputAssembly>
</ProjectReference>
</ItemGroup>
I think it takes the URL from the WebApp .csproj file:
IDE:- VS.NET 2013 (Update 2)
WIX version used : 3.9
Windows service MSI :- I am unable to change the platform to x64 bit and save it. If i change it to x64 option and save the build properties and close the property window, then reopen the property window again. The x86 option pops up again.. Although, the DLL's used in the project are coming as 64 bit based.
It is very annoying and frustrating. After i hit the Build on the ServiceSetup project, the .MSI file get generated. The MSI contains the windows service .exe file which unfortunately is 32 bit based. I want the windows service .exe file to be 64 bit.
Please suggest any soln.
This is a known bug in WiX v3.9: https://github.com/wixtoolset/issues/issues/3918
I had this same issue. It was very frustrating.
Somehow I got around it by:
Open configuration Manager
Create a new "x64" solution platform, without copying settings from the x86 and "Create new solution platforms" checked.
Ensure in this configuration manager window, the Active solution platform and the platform dropdown for the project are both x64 .. If needed, delete the x86 options from the configuration manager
Go to the Project Properties> Build tab
Ensure the platform dropbox says Active(x64), if not, select it.
Re-open the Build tab and check it still has the Active(x64). Sometimes the build active platform would switch to x86 when I put it as x64, but you first need to ensure step 3 is set.
Justin's solution didn't work for me. Although I could create the x64 platform, x86 stubbornly came back as the only option. My solution is as follows:
(1) Create a new Setup Project for WiX v3.
(2) Close the solution and open the .wixproj file in an extern editor like notepad+.
(3) The file contains only PropertyGroup elements for x86. After that insert the following PropertyGroup elements:
<!-- Insert -->
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|x64' ">
<DefineConstants>Debug</DefineConstants>
<OutputPath>bin\$(Platform)\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Platform)\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|x64' ">
<OutputPath>bin\$(Platform)\$(Configuration)\</OutputPath>
<IntermediateOutputPath>obj\$(Platform)\$(Configuration)\</IntermediateOutputPath>
</PropertyGroup>
(4) Reopen the project. Select Configuration Manager.
Under Project contexts, you can now select x64 in the drop down list. Do it.
(5) The drop down list of Active solution platform still only has x86. Select “New…” In the “New Solution Platform” dialog create the x64 platform.
(6) In the final step synchronize the settings of the solution platform with the project platform so that the four configuration | platform pairs are the same.
Source for step 3: WIX project fails building in X64 platform.
This particular problem is a big one.
In my current configuration Visual Studio 2013 builds my project if it is in Debug configuration, but not if it is in Release configuration.
Somehow when I select Release, 160 errors pup up and when I go through them they are in impossible places. Here is one example.
Visual studios Error is the following:
Error 3 ; expected E:\Users\Robert\Documents\Visual Studio 2013\Projects\GW2.NET\GW2.NET\GW2.NET\V1\MapInformation\DataProvider\ContinentData.cs 96 36 GW2.NET
And here is the code in question:
public static async Task<T> GetContentAsync<T>(string apiMethod, List<KeyValuePair<string, object>> arguments, Categories category)
{
var response = await GetJsonAsync(apiMethod, arguments, category);
return await Task.Factory.StartNew(() => JsonConvert.DeserializeObject<T>(response));
}
You see there isn't any error. If there were one, the Debug configuration wouldn't build either. I already tried to clean the solution and got the latest from TFS, and I deleted and recreated the configurations.
For now I am at my wit's end. How can I fix this?
The project is a C# 4.0 project with the Microsoft async, JSON.NET, and Rest# packages.
If you are really stuck, one thing you could do is open up the .csproj file in a text or XML editor and inspect the actual XML content in there. You're trying to figure out what settings/properties are set differently based on Debug/Release configurations. This might give you some insight into what it is doing different between the two configurations.
OK, if anyone else has the same problem, here is what I did. Thanks to Dylan Smith, I got to the solution.
Open your .csproj file with a text editor of your choice. I used Notepad++, but Visual Studio is also working. At the top there should be elements called PropertyGroup. Those elements define your build configurations. For me there were two:
One for Debug:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">
<DebugSymbols>true</DebugSymbols>
<DebugType>full</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Debug\</OutputPath>
<DefineConstants>DEBUG;TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<PlatformTarget>x86</PlatformTarget>
<DocumentationFile>bin\Debug\GW2.NET.XML</DocumentationFile>
</PropertyGroup>
And one for Release:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<DebugType>none</DebugType>
<Optimize>true</Optimize>
<OutputPath>bin\Release\</OutputPath>
<DefineConstants>TRACE</DefineConstants>
<ErrorReport>prompt</ErrorReport>
<WarningLevel>4</WarningLevel>
<DocumentationFile>bin\Release\GW2.NET.XML</DocumentationFile>
<LangVersion>4</LangVersion>
<PlatformTarget>x86</PlatformTarget>
</PropertyGroup>
Apart from the obvious differences, with the first two nodes (DebugSymbols and DebugType), the main difference was the LangVersion element. I deleted it and voilà the project builds in release mode too.
So if you have the same problem as me, open the .csproj file and delete this node. This should solve it.
P.S.: What does the LangVersion element mean? If I change it from 4 to, say, 4.0, I get the following error:
Invalid option '4.0' for /langversion; must be ISO-1, ISO-2, 3, 4, 5 or Default
If you are building a WiX setup project using Visual Studio 2010 with your own custom dialog boxes and your project builds in debug mode, but not in release mode, then go to menu Project → Properties → set Tool Settings to Release Mode and check the checkbox Suppress ICE validation.
The scenario is: I'm building my solution with TeamCity, I'm not running the build account as an administrator; so I get problems with the strong name keys.
I know of a few solutions out there, like running the build as an administrator and registering the certificates in the proper container.
Is there anyway to sign the assemblies within a solution file only during a release build and not during a debug build. Or are there any similar solutions?
I think it is strange that there isn't a MSBuild parameter that can be set wether the assemblies should be signed or not. Because if you look at the csproj-files there is an option there for signed or not signed
Another option is to edit the project file. By default if you enable assembly signing in Visual Studio it will be used for all build configurations. The project file contains an element like the following.
<PropertyGroup>
<SignAssembly>true</SignAssembly>
</PropertyGroup>
<PropertyGroup>
<AssemblyOriginatorKeyFile>YourKeyFile.pfx</AssemblyOriginatorKeyFile>
</PropertyGroup>
If you only want to sign the assemblies during a specifc build configuration, such as RELEASE. You can put the <SignAssembly> and <AssemblyOriginatorKeyFile> in the PropertyGroup element with the Condition that identifies your build configuration.
So if you want to sign your assembly during a release build, you can change your project file to the following.
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Release|AnyCPU' ">
<!-- other element of this PropertyGroup -->
<SignAssembly>true</SignAssembly>
<AssemblyOriginatorKeyFile>YourKeyFile.pfx</AssemblyOriginatorKeyFile>
</PropertyGroup>
Note: When you change your project file, to the following. you cannot change the signing settings of the Project Properties in Visual Studio. That means in Visual Studio is signing of the assembly disabled, also if you change the build configuration in Visual Studio.
Here's a solution where the assembly is signed in Release configuration, but not in Debug configuration. It uses the signing facilities from the project, not using the [AssemblyKeyFile] attribute. It's basically the same as Jehof's answer but in other words.
Set up the project for signing in the Signing tab in project preferences.
Unload the project, and edit it in the XML editor. Locate the SignAssembly property. Move that property into the two configuration dependent property groups. In the Debug configuration, set the property to false.
This will look something like this:
<PropertyGroup Condition=" '$(Configuration)' == 'Debug' ">
<!-- ... -->
<SignAssembly>false</SignAssembly>
</PropertyGroup>
<PropertyGroup Condition=" '$(Configuration)' == 'Release' ">
<SignAssembly>true</SignAssembly>
</PropertyGroup>
Visual Studio works correctly even when changing build configurations, with the exception of the Sign the assembly check box in the Signing tab. I tested with Visual Studio 2008.
Cave-Eats:
You need to remove the [AssemblyKeyFile] attribute for this to work.
If you have [InternalsVisibleTo] attributes, you need to maintain two versions, like this:
#if DEBUG
[assembly: InternalsVisibleTo("MyLib.NUnit")]
#else
[assembly: InternalsVisibleTo("MyLib.NUnit, PublicKey=<your public key>")]
#endif
In other words, MyLib.NUnit must also be signed in Release configuration.
You can use preprocessor directives:
#if SIGN
//Only the Release build is signed
#pragma warning disable 1699 //We can't use the compiler switch
[assembly: AssemblyKeyName("KeyContainerName")]
#pragma warning restore 1699
#endif
Then define the SIGN symbol in the Release configuration.
You must install the key into a key container using sn.exe. Alternatively, you can use [AssemblykeyFile] to specify a path.
The #pragma suppresses this warning.