I have an c# application that I am installing during cleanboot on a windows mobile 6.1 device. It installs correctly, however, I need to get it to autostart after cleanboot.
I always have to warmboot the handheld after cleanboot to make it start.
How can I avoid this?
I asume, you are using a CAB file to install your C# app during cleanboot.
You may use a setup.dll inside the cab to start your app after the cab files have been installed using the DLL's Install_Exit function call (setupdll sample for example here: http://www.codeproject.com/Articles/7724/Creating-Pocket-PC-Application-Setup-Packages-Usin). But MS states you cannot rely on calling files of the cab install itself.
Another approach would be a seond cab that is installed after your C# app install and just calls your app, even using a setup dll.
See also http://msdn.microsoft.com/en-us/library/bb158796.aspx for howto pack several cabs into one install.
The problem with cleanboot installers and AutoStart is, that the OS already has run \Windows\StartUp and also other autostarts when the cab has been installed. Therefor you normally need a reboot that then executes your app using StartUp (or HKLM\Init).
You may also use a scripting engine to install the cab and then launch your installed app. For example use MortScript, which supports being used as "AutoStart.exe" inside SD Card\2577 or similar dir (Volume name\2577). The the script can call wceload.exe to install your app and afterwards start the executable of the installed app. Something like using a batch.
As this is an Intermec install, you can use \Flash File Store\UserAutoInstall_sstransferagent.xml to automate the install and launch of the app.
For example: Your cab is at \Flash File Store\MyInstall\MyCab.cab and installs MyApp.exe to \Program Files\MyApp:
<?xml version="1.0"?>
<Devices>
<Device Type="" Family="" Model="" Boot="">
<Files SrcDir="\Flash File Store\UserAutoInstall">
<File SrcName=""
DestName="wceload.exe"
DestDir="\Windows"
Run="true"
CmdLine='"\Flash File Store\MyInstall\MyCab.cab" /silent /verifyconfig /nodelete'
/>
<File SrcName=""
DestName="MyApp.exe"
DestDir="\Program Files\MyApp\MyApp.exe"
Run="NoWait"
CmdLine=''
/>
</Files>
</Device>
</Devices>
regards
Related
I am trying to launch a full-trust process program from my UWP app. I am using the PackageManager in my full-trust process to locate UWP packages to launch files or links, so I need to run it as an admin.
When I try running the full-trust process, it opens and works properly on my machine (I am running an admin account). However, when I look up the process in the Task Manager, it does not run elevated.
I'm just worried that it may not work on any other machine (non-admin) out there. Here's my code I'm using in Package.appxmanifest, courtesy of Stefan Wick (https://stefanwick.com/2018/10/07/app-elevation-samples-part-3/):
<desktop:Extension Category="windows.fullTrustProcess" Executable="Assets\NitishTest.exe">
<desktop:FullTrustProcess>
<desktop:ParameterGroup GroupId="Parameters" Parameters="parameters" />
</desktop:FullTrustProcess>
</desktop:Extension>
<uap3:Extension Category="windows.appExecutionAlias"
Executable="Assets\NitishTest.exe"
EntryPoint="Windows.FullTrustApplication">
<uap3:AppExecutionAlias>
<desktop:ExecutionAlias Alias="NitishTest.exe" />
</uap3:AppExecutionAlias>
</uap3:Extension>
I am not using a Windows Application Packaging Project, however. Could this be the reason why it's not working properly elevated?
I am trying to run a Asp.Net Core 3 application in Ubuntu 19.10 thru terminal using dotnet run command but it does not seem to work. I get this error.
Process terminated. Couldn't find a valid ICU package installed on the system.
Set the configuration flag System.Globalization.Invariant to true if you want
to run with no globalization support.
at System.Environment.FailFast(System.String)
at System.Globalization.GlobalizationMode.GetGlobalizationInvariantMode()
at System.Globalization.GlobalizationMode..cctor()
at System.Globalization.CultureData.CreateCultureWithInvariantData()
at System.Globalization.CultureData.get_Invariant()
at System.Globalization.CultureInfo..cctor()
at System.StringComparer..cctor()
at System.StringComparer.get_OrdinalIgnoreCase()
at Microsoft.Extensions.Configuration.ConfigurationProvider..ctor()
at Microsoft.Extensions.Configuration.EnvironmentVariables.EnvironmentVariablesConfigurationSource.Build(Microsoft.Extensions.Configuration.IConfigurationBuilder)
at Microsoft.Extensions.Configuration.ConfigurationBuilder.Build()
at Microsoft.AspNetCore.Hosting.GenericWebHostBuilder..ctor(Microsoft.Extensions.Hosting.IHostBuilder)
at Microsoft.Extensions.Hosting.GenericHostWebHostBuilderExtensions.ConfigureWebHost(Microsoft.Extensions.Hosting.IHostBuilder, System.Action'1<Microsoft.AspNetCore.Hosting.IWebHostBuilder>)
at Microsoft.Extensions.Hosting.GenericHostBuilderExtensions.ConfigureWebHostDefaults(Microsoft.Extensions.Hosting.IHostBuilder, System.Action'1<Microsoft.AspNetCore.Hosting.IWebHostBuilder>)
at WebApplication.Program.CreateHostBuilder(System.String[])
at WebApplication.Program.Main(System.String[])
I installed the dotnet core sdk using the ubuntu store and after that I also installed Rider IDE.
The weird thing here is that when I run the app using Rider it runs fine, the only issue is using terminal dotnet core commands.
Does anybody know what might be the issue ?
The application is created using Rider. I don't think that this plays a role but just as a side fact.
I know there are also other ways to install dotnet core in ubuntu but since the sdk is available in the ubuntu story I thought it should work out of the box and of course its an easier choice.
Also tried this one but does not seem to work for me. Still the same issue happens after running the commands.
The alternative solution as described in Microsoft documentation is to set environment variable before running your app
export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1
If you want to run with no globalization support, you need to get "System.Globalization.Invariant": true into your published output AppName.runtimeconfig.json file as shown in the example below:
{
"runtimeOptions": {
"tfm": "netcoreapp3.0",
"configProperties": {
"System.GC.Server": true,
"System.Globalization.Invariant": true
}
}
}
You can add it manually every time you deploy by adding or updating the AppName.runtimeconfig.json file. Better yet, add it once to a runtimeconfig.template.json file like this:
{
"configProperties": {
"System.Globalization.Invariant": true
}
}
Make sure that runtimeconfig.template.json is included in build/publish.
It seem the package libicu63 will provide the ico support for dotnet on Linux, at least on Debian'ish distros.
Update:
And it seems it's "missing" when doing a small installing of Debian (i.e. deselect all applications/system-options in the installation program, except for SSH server)
The trick around it on Ubuntu 20.04 based on this thread https://github.com/dotnet/core/issues/2186#issuecomment-671105420
$export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1
Yes. When installing Github action in Debian. It is also required.
As the response from MrCalvin,
sudo apt-get update && sudo apt-get install -qqq libicu63 resolve my issue.
edit your .bashrc file by adding the following line, e.g.:
nano ~/.bashrc
add
export DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=1
Ctrl+o, Ctrl+x
restart terminal and run pwsh again
I had this issue while trying to run Umbraco version 9.2.0. Fiddling with System.Globalization.Invariant was not a good solution as it broke globalization in the backoffice. This issue has been solved in v9.4: https://github.com/umbraco/Umbraco-CMS/pull/11961
I didn't want to upgrade my Umbraco version to solve this, so I just copied the change in that commit to my project.
Simply go into the .csproj file of your web project and change the ICU package reference lines to:
<!-- Force windows to use ICU. Otherwise Windows 10 2019H1+ will do it, but older windows 10 and most if not all winodws servers will run NLS -->
<ItemGroup>
<PackageReference Include="Microsoft.ICU.ICU4C.Runtime" Version="68.2.0.9" />
<RuntimeHostConfigurationOption
Condition="$(RuntimeIdentifier.StartsWith('linux')) Or $(RuntimeIdentifier.StartsWith('win')) Or ('$(RuntimeIdentifier)' == '' And !$([MSBuild]::IsOSPlatform('osx')))"
Include="System.Globalization.AppLocalIcu"
Value="68.2.0.9" />
</ItemGroup>
In my case, I followed the Windows documentation to install SDK dependencies and Runtime, watch out for the corresponding version to each Linux distribution to avoid compatibility issues.
This helped me override the default ICU version to the one that's installed on the machine running arch linux.
export CLR_ICU_VERSION_OVERRIDE=$(pacman -Q icu | awk '{split($0,a," ");print a[2]}' | awk '{split($0,a,"-");print a[1]}')
EDIT 04/06/18 => Updated question with last status
So I have this working .Net 4.6 Stateful Service that currently run on my Windows Service Fabric cluster deployed on Azure.
Starting from 09/2017, I should be able to move to Linux: https://blogs.msdn.microsoft.com/azureservicefabric/2017/09/25/service-fabric-6-0-release/
So I'm trying to deploy it on Linux so I can save costs.
First things first, I've migrated all my code from .Net 4.6 to .Net Core 2.0. Now I can compile my binaries without issues. I've basically created new .Net Core projects and then moved all my source code from .Net 4.6 projects to the new .Net Core ones.
Then I've updated my Service Fabric application. I removed my previous SF services from my sfproj, then I've added my new .Net Core ones.
Looks like there is a warning (nothing on the output window though), but it's here anyway if I try to create a new empty Statful service using .Net core 2.0 through the template provided by Service Fabric Tools 2.0 (beta):
So I'm going to live with it.
On my dev machine, I've modified the 2 csproj projects that contain my Stateful services so they can run locally as Windows executables. I've used the win7-x64 runtimeIdentifier.
Running my SF cluster locally on my Windows machine is fine.
Then I've slightly changed the previous csproj files for Linux. I used the ubuntu.16.10-x64 runtimeIdentifier.
Also I've changed the ServiceManifest.xml file to target the linux-compatible binary:
<!-- Code package is your service executable. -->
<CodePackage Name="Code" Version="1.9.6">
<EntryPoint>
<ExeHost>
<Program>entryPoint.sh</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
entryPoint.sh is a basic script that eventually executes:
dotnet $DIR/MyService.dll
Then I've successfully deployed to my secured SF Linux cluster from Visual Studio. Unfortunately I have the following errors for both my stateful services:
Error event: SourceId='System.Hosting',
Property='CodePackageActivation:Code:EntryPoint'. There was an error
during CodePackage activation.The service host terminated with exit
code:134
Looks like my binary crashes when starting. So here are my questions:
Is the approach right to deploy a C# .Net Core SF stateful service on Linux from Visual Studio?
EDIT: looking inside the LinuxsyslogVer2v0 table, I get the following error:
starthost.sh[100041]: Unhandled Exception:
System.IO.FileLoadException: Could not load file or assembly
'System.Threading.Thread, Version=4.1.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a'. The located assembly's manifest
definition does not match the assembly reference. (Exception from
HRESULT: 0x80131040)
I found the following bug report: https://github.com/dotnet/sdk/issues/1502
Unfortunately, I still get the error without using MSBuild (using dotnet deploy).
EDIT: further clarification:
My boss want me to run on Linux because starting from D1v2 machines, it's half the price compared to Windows machines (no license etc.)
My .NET Core 2.0 services successfully run on Windows. So the .NET Core port should be fine.
So, this was a real pain in the ass to get it working properly. But it works. Well, kind of.
First, Reliable Services are still in preview on Linux: https://github.com/Microsoft/service-fabric/issues/71
Full Linux support should come very soon (actually it should be available already according to the previous link...).
Now for the details about how to procede, here is some information to help others, because there is just nothing about that on Microsoft documentation and I literally lost 3 days trying to make it work.
1. Do use .NET Core 2.0 for your projects.
It is supported on Linux. On preview for now, but it works.
2. Do use the right RID for your projects.
As of today (April 2018), the right RID to use is ubuntu.16.04-x64.
Edit the csproj files of your Reliable Service projects and set the RID like this:
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifier>ubuntu.16.04-x64</RuntimeIdentifier>
<Platforms>AnyCPU;x64</Platforms>
</PropertyGroup>
The fun part is, you should be able to provide multiple RIDs using the RuntimeIdentifiers parameter (with a S at the end) like that:
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifiers>win7x64;ubuntu.16.04-x64</RuntimeIdentifiers>
<Platforms>AnyCPU;x64</Platforms>
</PropertyGroup>
So you could build Windows binaries and Linux binaries at the same time.
But it simply doesn't work. When building the project from Visual Studio, I end up with the following directory only:
bin/Debug/netcoreapp2.0/
Only DLLs, no valid entry point. No win7-x64 folder, no ubuntu.16.04-x64, no nothing.
This is a bug, supposed to be fixed, but it's not (I use Visual Studio 15.6.2 all up-to-date as of today). See https://github.com/dotnet/core/issues/1039
3. You need a valid Entry Point for your service.
On Windows it's an executable file (*.exe). On Linux it's not. I ended up getting the Linux C# example and copied/pasted the entry point. https://learn.microsoft.com/en-us/azure/service-fabric/service-fabric-create-your-first-linux-application-with-csharp
So basically I now have on my ServiceManifest.xml file of each Reliable Service the following EntryPoint :
<?xml version="1.0" encoding="utf-8"?>
<ServiceManifest Name="XXXX"
Version="1.0.0"
xmlns="http://schemas.microsoft.com/2011/01/fabric"
xmlns:xsd="http://www.w3.org/2001/XMLSchema"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<ServiceTypes>
<!-- This is the name of your ServiceType.
This name must match the string used in RegisterServiceType call in Program.cs. -->
<StatefulServiceType ServiceTypeName="YYY" HasPersistedState="true" />
</ServiceTypes>
<!-- Code package is your service executable. -->
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost>
<Program>entryPoint.sh</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
entryPoint.sh is as follows:
#!/usr/bin/env bash
check_errs()
{
# Function. Parameter 1 is the return code
if [ "${1}" -ne "0" ]; then
# make our script exit with the right error code.
exit ${1}
fi
}
DIR=`dirname $0`
echo 0x3f > /proc/self/coredump_filter
source $DIR/dotnet-include.sh
dotnet $DIR/NAME_OF_YOUR_SERVICE_DLL.dll $#
check_errs $?
dotnet-include.sh is as follows:
#!/bin/bash
. /etc/os-release
linuxDistrib=$ID
if [ $linuxDistrib = "rhel" ]; then
source scl_source enable rh-dotnet20
exitCode=$?
if [ $exitCode != 0 ]; then
echo "Failed: source scl_source enable rh-dotnet20 : ExitCode: $exitCode"
exit $exitCode
fi
fi
Both are inside the PackageRoot folder. I specified for both their properties so the Build Action is "Content" and the Copy to Output Directory is "Copy always".
4. Do NOT build using MSBuild !!
Yeah it is supposed to build Linux packages too, or at least it seems so, because MSBuild is able to produce the following files when you right click on your project and click "Build":
Don't trust the apparent success of the operation, it will miserably FAIL to properly execute when deployed. Some *.so files missing and other issues. MSBuild is buggy as hell and misbehaves regarding dependencies.
See for instance this bug report: https://github.com/dotnet/sdk/issues/1502
Still not fixed after almost a year...
Or https://github.com/dotnet/core/issues/977 (got this one, too).
5. Do write some PowerShell script to build the stuff by yourself.
I ended up reinventing the wheel using the following script to build my package:
# Creating binaries for service 1
cd DIRECTORY_OF_MY_SERVICE_1
dotnet publish -c Release -r ubuntu.16.04-x64
# Creating binaries for service 2
cd ..\DIRECTORY_OF_MY_SERVICE_2
dotnet publish -c Release -r ubuntu.16.04-x64
# Creating binaries for service 3
cd ..\DIRECTORY_OF_MY_SERVICE_3
dotnet publish -c Release -r ubuntu.16.04-x64
# Copying ApplicationManifest.xml
cd ..
mkdir PKG\ServiceFabricApplication
echo F|xcopy "ServiceFabricApplication\ApplicationPackageRoot\ApplicationManifest.xml" "PKG\ServiceFabricApplication\ApplicationManifest.xml" /sy
# Copying Service1 files
mkdir "PKG\ServiceFabricApplication\Service1Pkg"
mkdir "PKG\ServiceFabricApplication\Service1Pkg\Code"
xcopy "Service1\PackageRoot\*" "PKG\ServiceFabricApplication\Service1Pkg" /sy /D
xcopy "Service1\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service1Pkg\Code" /sy
# Copying Service2 files
mkdir "PKG\ServiceFabricApplication\Service2Pkg"
mkdir "PKG\ServiceFabricApplication\Service2Pkg\Code"
xcopy "Service2\PackageRoot\*" "PKG\ServiceFabricApplication\Service2Pkg" /sy /D
xcopy "Service2\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service2Pkg\Code" /sy
# Copying Service3 files
mkdir "PKG\ServiceFabricApplication\Service3Pkg"
mkdir "PKG\ServiceFabricApplication\Service3Pkg\Code"
xcopy "Service3\PackageRoot\*" "PKG\ServiceFabricApplication\Service3Pkg" /sy /D
xcopy "Service3\bin\Release\netcoreapp2.0\ubuntu.16.04-x64\publish\*" "PKG\ServiceFabricApplication\Service3Pkg\Code" /sy
# Compresses the package
Write-host "Compressing package..."
Copy-ServiceFabricApplicationPackage -ApplicationPackagePath .\PKG\ServiceFabricApplication -CompressPackage -SkipCopy
sfproj file is a Visual Studio / MSBuild related project, so you need to build everything by yourself.
The script above produces the same content as the pkg folder created by MSBuild when building your sfproj using Visual Studio. It copies everything on a PKG folder at the root of your solution.
The package structure is detailed here: https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/service-fabric/service-fabric-package-apps.md
6. Now it's time to deploy!
At this point I didn't trusted Visual Studio anymore, so I built my own PowerShell script:
. .\ServiceFabricApplication\Scripts\Deploy-FabricApplication.ps1 -ApplicationPackagePath '.\PKG\ServiceFabricApplication' -PublishProfileFile '.\ServiceFabricApplication\PublishProfiles\Cloud.xml' -DeployOnly:$false -ApplicationParameter:#{} -UnregisterUnusedApplicationVersionsAfterUpgrade $false -OverrideUpgradeBehavior 'None' -OverwriteBehavior 'SameAppTypeAndVersion' -SkipPackageValidation:$false -ErrorAction Stop
It reuses the Deploy-FabricApplication.ps1 script provided by the Service Fabric project template inside the sfproj project. This script parses the Cloud.xml PublishProfile and deploys to your service fabric cluster.
So you specifies the rights values on both PublishProfiles/Cloud.xml and ApplicationParameters/Cloud.xml then execute the script.
It only works if you have the certificate used to secure the cluster installed on your machine, of course.
Do note the first dot '.' is important, because if you don't use it, you'll have the following error:
Get-ServiceFabricClusterManifest : Cluster connection instance is null
See https://stackoverflow.com/a/38104087/870604
Oh, and as there are bugs on the Service Fabric SDK too, you might want to shutdown your local SF cluster too...
https://github.com/Azure/service-fabric-issues/issues/821
7. Now it's time for another deception.
It simply doesn't work, the service crashes on startup. After searching hours inside the LinuxsyslogVer2v0 Azure Storage table (the log table for Linux, located in one of the two Azure Storage Accounts created automatically with the SF cluster), I found that Microsoft own Nuget Packages were buggy too.
Specifically, the Nuget package Microsoft.Azure.Devices doesn't work on version 1.6.0. An issue with a reference of a dll not found or whatever. I rollbacked to a previous version, namely 1.5.1, and it was fixed.
At this point I didn't had anymore energy to create another Github issue about that. Sorry MS, I'm not your QA team, I'm getting tired.
8. Build again using the first PowerShell script, deploy using the second PowerShell script, and you're done.
You've finally deployed C# Reliable Services using .NET Core 2.0 from Visual Studio (kind of, as it's buggy and I used PowerShell) on Windows to a Linux SF Cluster.
Now I still have issues with my ASP.NET Core service, but it will be a story for another day.
Conclusion: TL;DR
The whole thing is a mess. Bugs everywhere. In the SDK, in the tools, in some of Microsoft Nuget Packages. Awful experience. But it is supported (in preview for now) and you can make it work. Hope this post will help...
I was having similar issues, but I believe this is the issue:
In this release, .NET Core 2.0 services are only supported on Service Fabric for Windows. Full cross-platform support for .NET Core 2.0 services on Windows and Linux is coming soon.
From the Service Fabric 6.1 Release Notes
So no Linux as long as you are targeting .net core 2.0.
I have success deploy to Linux service fabric with this help
Open all the service .csproj files and update the RuntimeIdentifier as shown below
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp2.0</TargetFramework>
<IsServiceFabricServiceProject>True</IsServiceFabricServiceProject>
<RuntimeIdentifier>linux-x64</RuntimeIdentifier>
</PropertyGroup>
Update the ServiceManifest.xml to remove .exe extension as shown below
<CodePackage Name="Code" Version="1.0.0">
<EntryPoint>
<ExeHost>
<Program>Web1</Program>
</ExeHost>
</EntryPoint>
</CodePackage>
See https://blogs.msdn.microsoft.com/premier_developer/2018/05/27/running-net-core-2-0-applications-in-a-linux-service-fabric-cluster-on-azure/
*Visual Studio 15.7.3
I've been trying to wrap WPF app inside a Windows Universal App, using Desktop Bridge.
In order to make the app's taskbar icon unplated, with transparent background, I followed the instructions that can be found in various blogs and MSDN articles/forums, such as this one.
The first commands I've been executing are these two:
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\makepri.exe" createconfig /o /cf priconfig.xml /dq en-US
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\makepri.exe" new /o /pr . /cf priconfig.xml
These commands were executed in the WPF app's output folder, where I also put an AppxManifest.xml file, along with the files and folders referenced by it (such as the Executable file and the Assets' images in various scales and resolutions).
From this point, I got two different weird errors:
First, If the AppManifest.xml file contains the following section:
<Extensions>
<desktop2:Extension Category="windows.firewallRules">
<desktop2:FirewallRules Executable="app\MyWpfApp.exe">
<desktop2:Rule Direction="in" IPProtocol="TCP" Profile="all" />
<desktop2:Rule Direction="in" IPProtocol="UDP" Profile="all" />
</desktop2:FirewallRules>
</desktop2:Extension>
</Extensions>
then the second makepri command will result in the following error message:
onecoreuap\base\mrt\tools\indexertool\src\tool\parametermanager.cpp(:908): error PRI175: 0x80080204 -
onecoreuap\base\mrt\tools\indexertool\src\tool\parametermanager.cpp(:318): error PRI175: 0x80080204 -
Microsoft (R) MakePRI Tool
Copyright (C) 2013 Microsoft. All rights reserved.
error PRI191: 0x80080204 - Appx manifest not found or is invalid. Please ensure well-formed manifest file is present. Or specify an index name with /in switch.
Then if I remove that FirewallRules section, everything seems to run fine - at least on my machine.
Second, It doesn't always run as expected:
when I try to run exactly the same files (with the fixed version of AppxManifest.xml) and same commands on a different machine, I get the same error that I used to get in the first machine (from before removing the FirewallRules section).
Any idea what could be causing these problems? What possible differences between the build machines could cause the second problem? What should I look for?
The first problem was solved by removing the IgnorableNamespaces property from the Package xml-element (at the root level of AppxManifest.xml).
--
As for the second problem, after contacting Microsoft's support team about this issue, this seems to be a bug in the makepri tool running on older systems:
Apparently, when running on Windows Server 2012 R2 (and perhaps other version as well), the makepri tool command has to supplied with another "optional" parameter that states the app's name:
"C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64\makepri" new /o /pr . /cf priconfig.xml /mn AppxManifest.xml /of resources.pri /in "MyAppName"
The important part is the /in "MyAppName" argument at the end of the line, though the other arguments might be crucial as well. Also, "MyAppName" has to be the same as defined in the AppxManifest.xml file, in that part:
<Applications>
<Application Id="MyAppName" ...>
...
Another step that might have been relevant to solve this issue, was to make sure that the file-mappings file, used later for the makeappx command, has the correct definition for ResourceId - as explained in this article.
I have developed an msi setup using WIX which consists of a desktop application as well as a windows service and both are running on C# .Net 3.5 framework. My windows service starts only when any user logs into the system which triggers the desktop application to start. The windows service is made to run as Local System. The msi setup is getting installed successfully at Win-8, Win-7 and Windows-XP but showing "File In Use" message while doing uninstallation even the service is not removed from the SCM. I have given the below codes at the OnStop() method of the service and inside the WIX page respectively.
onStop() method:
Process[] workers = Process.GetProcessesByName("filename");
workers[0].WaitForExit(1000);
workers[0].Kill();
workers[0].Dispose();
workers[0].Close();
Product.wxs inside WIX:
<ServiceInstall Id="ServiceInstaller" Name="Servicename"
DisplayName="service display name" Description="service description"
Start="auto" Account="LocalSystem" ErrorControl="normal"
Type="ownProcess"></ServiceInstall>
<ServiceControl Id="ServiceInstallerControl" Name="Servicename"
Start="install" Stop="both" Remove="uninstall" Wait="yes" />
The service is not removed from the SCM at all and the below popup message is displaying at the time of uninstallation process.
I have worked around with the WIX to solve the problem but unable to do so.
Any kind of help in this regard will be highly appreciated.
I'd recommend you to create custom action that handles the uninstall.You can create a batch file with the uninstall details , and then simply execute the batch file from the custom action( as a process).Its good practice to create installation and uninstall batch files with your service.