Brokered components when using TFS Build - c#

When using TFS to build my application, it fails when I have an application with Brokered components.
Here is what I am using in my Package.appxmanifest, and it works when I build/run locally. How can I still build/deploy using TFS and keep my brokered components? Is this possible?
<Extensions>
<Extension Category="windows.activatableClass.inProcessServer">
<InProcessServer>
<Path>clrhost.dll</Path>
<ActivatableClass ActivatableClassId="BrokeredRuntimeComponent.{ClassName}" ThreadingModel="MTA">
<ActivatableClassAttribute Name="DesktopApplicationPath"
Type="string"
Value="C:\Source\{AppName}\Debug\BrokeredRuntimeComponentProxy" />
</ActivatableClass>
</InProcessServer>
</Extension>
</Extensions>
When I run the build, I get the following error. I do not have access to run the regsvr32 /s on our TFS. Is this something that needs to be done on every client or can it be done on the build server and run on every device? I think it might work if it's possible to get the build service to run as administrator. Is this even possible?
C:\Program Files (x86)\MSBuild\Microsoft.Cpp\v4.0\V120\Microsoft.CppCommon.targets (1620): Failed to register output. Please try enabling Per-user Redirection or register the component from a command prompt with elevated permissions.
Please let me know if anything I've put here is unclear so I can hopefully clarify.

You need to have everything installed on your build server that your need to run a build locally. If you need certain registered components then that needs done in advance or at build time.
If at build time then the account that TF build runs under needs permission to perform that action.

Related

UWP LaunchFullTrustProcessForCurrentAppAsync - EXE file not found

We are creating a UWP application which is intended for Side loading only.
At various times this application needs to reboot the PC (it's desktop only), to do this we intend to use LaunchFullTrustProcessForCurrentAppAsync() to call a simple external EXE which uses Process.Start("shutdown") to reboot the PC.
We have created the EXE called RebootPC.exe and on it's own it works fine.
We now include it in our UWP project:
First we add the desktop and rescap namespaces to our project and we also add rescap to our IgnorableNamspaces
xmlns:desktop="http://schemas.microsoft.com/appx/manifest/desktop/windows10"
xmlns:rescap="http://schemas.microsoft.com/appx/manifest/foundation/windows10/restrictedcapabilities"
IgnorableNamespaces="uap mp uap5 rescap">
Then, we then modify the Extension section to include our EXE, we know we cannot put the EXE in our project root as C# compiler removes it so we have put it in a sub folder (in this case \Assets). We also set the EXE's type to 'Content' and 'Copy always' in the Solution explorer
<desktop:Extension Category="windows.fullTrustProcess" Executable="Assets\RebootPC.exe">
<desktop:FullTrustProcess>
<desktop:ParameterGroup GroupId="rebooter" Parameters=""/>
</desktop:FullTrustProcess>
</desktop:Extension>
finally in the manifest we add rescap to the Capabilities section - we know it has to be first in the list otherwise you get a manifest error when packaging
<Capabilities>
<rescap:Capability Name="runFullTrust"/>
<Capability Name="internetClient" />
<DeviceCapability Name="bluetooth" />
<DeviceCapability Name="radios" />
OK, so the manifest is changed. We now go to our C# code:
In that we perform the following:
if (ApiInformation.IsApiContractPresent("Windows.ApplicationModel.FullTrustAppContract", 1, 0))
{
try
{
await Windows.ApplicationModel.FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync();
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
}
When we build and run the project in Visual Studio it seems to work fine, under the intended circumstances the PC will reboot as intended.
The problem comes when we try to package it for installation on other PCs. We use Store->Create App Packages (remember this application is for side loading only).
The creation of the package works fine and we can install it on other PCs with no problem. The problem is that when we run the Application and it comes time to run the external EXE to reboot the PC a command window opens but we get an exception saying "System can't find c:\users.......\Assets\RebootPC.exe"
So, even though the packaging is done without error and even though we have set the properties of RebootPC.exe to 'Content' and 'Copy always' it is either not being included in the package or not being installed along with the App?
So, does anyone know how we can check if it is being included in the package? and if so how we can check if and where it is being installed on the target machine? or has anyone else had this issue and found the solution?
This has had us baffled for days and is driving us crazy!!!
UPDATE: I think the issue may not be that RebootPC.exe can't be found but rather shutdown.exe - If this is the case then it's a bit of a school boy error!!!
Anyway, I will sort this and see if that fixes the issue
I will leave the rest of the question up as it might provide useful information for others
As Mentioned in the official sample the exe file has to in the Appx folder of your project
Make sure the RebootPC.exe was copied to the Appx folder -
UWP\bin\x64\Release\AppX if not rebuild the solution or copy it
manually.
https://github.com/Microsoft/DesktopBridgeToUWP-Samples/tree/master/Samples/AppServiceBridgeSample#builddeploy-and-run-the-sample
try
{
await Windows.ApplicationModel.FullTrustProcessLauncher.LaunchFullTrustProcessForCurrentAppAsync("rebooter");
}
catch (Exception ex)
{
Debug.WriteLine(ex.Message);
}
}

WIX is not stopping windows service on unistall

I am struggling with very strange situation with wix installer.
I have custom BA app which installs windows service and removes it on uninstall.
On Win XP everything is working perfectly but on Win 10 service is not stopped and not removed though uninstallation processed successfully.
In log files I cannot see any errors related to this.
Any ideas?
This is service install configuration:
<ServiceInstall
Id="MyServiceInstaller"
Type="ownProcess"
Name="MyService"
DisplayName="My Service"
Description="My Service"
Start="auto"
Account="[SERVICEACCOUNT]"
Password="[SERVICEPASSWORD]"
ErrorControl="normal" />
<ServiceControl Id="StartMyService"
Name="MyService"
Start="install"
Wait="no" />
<ServiceControl Id="StopMyService"
Name="MyService"
Stop="both"
Remove="uninstall"
Wait="yes" />
Round 2:
I jumped the gun here. As Chris says, we do need to see the log. I assumed the uninstall was hanging, which it does not seem to be at all.
ARP: I suppose you should quickly check if there are two product entries in Add / Remove Programs first of all? (don't think that is the problem either - failed major upgrade).
SharedDllRefCount: Is the SharedDllRefCount attribute set to yes for the service component? Please post the whole component markup, with all attributes specified - conditions and all. If the component was set permanent, that would explain things, but then the uninstall wouldn't work on XP. Enabling SharedDllRefCount sets the legacy ref-count here:
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\SharedDLLs
HKLM\SOFTWARE\Wow6432Node\Microsoft\Windows\CurrentVersion\SharedDLLs
Some SharedDllRefCount cleanup details here: MSI not uninstalling .dll files
Conditions Table: Are there any entries in the Condition table? (Feature conditions).
Round 1 (misunderstood the question - again - a couple of items still apply):
Debug Logging: Perhaps try to run your uninstall with verbose, debug logging to see if you can get some more information about what the problem can be:
msiexec.exe /x {ProductCode} /L*vx! C:\Your.log
Security Software: Is there anti-virus or security software on the problem box? If so, try to disable it before you run the uninstall.
Event Log: Maybe have a quick look for any clues in the event viewer? (Windows + Tap R. type eventvwr and pressOK). Check the different logs.
Custom Actions: Do you have any custom actions that run on uninstall? If so, what type of custom action? Managed code?
Service Credentials: Is the password for the service account still valid on that problem box? If worst comes to worst, can you log on with those service credentials (if that is possible) and try to start and stop the service to check for errors? Maybe even try to run the service with your own admin account? This is not ideal any of it, and should only be done to get to the bottom of this.
There have been a lot of service questions on StackOverflow lately. Here are some recent answers:
Wix - ServiceControl start takes four minutes to fail, should be 30 sec
Wix Service Installer sometimes fails to install or start
Wix installer: installed service unable to read HKLM registry entries on start

TypeLoadException using WinRT Brokered Component

I am building a Windows Store App using a brokered component. The brokered component is meant to enable interaction with an RFID reader on the device. When I try to initialize an instance of the class exposed by the brokered component, I received a System.TypeLoadException with the message Could not find or load a type. (Exception from HRESULT: 0x80131522).
I'm working against a clean installation of Windows 8.1 Professional on two different tablet devices. Both are currently experiencing this issue. The solution has worked in the past; something I've done recently must be causing this. I've also verified that the RFID reader can be accessed using a sample application provided by the hardware vendor.
My Package.appxmanifest file looks similar to this:
<Package ...>
...
<Extensions>
<Extension Category="windows.activatableClass.inProcessServer">
<InProcessServer>
<Path>clrhost.dll</Path>
<ActivatableClass ActivatableClassId="MyApp.RFID.Component.RfidDevice" ThreadingModel="STA">
<ActivatableClassAttribute Name="DesktopApplicationPath" Type="string" Value="C:\Program Files (x86)\MyApp\RFID" />
</ActivatableClass>
</InProcessServer>
</Extension>
</Extensions>
</Package>
The solution is being built to target an x86 platform. I've registered my components on the target device under C:\Program Files (x86)\MyApp\RFID using the following commands (per this whitepaper):
icacls . /T /grant "ALL APPLICATION PACKAGES":RX
regsvr32 MyApp.RFID.Proxy.dll
I've installed the Visual Studio 2013 x86 Redistributable Package on the target device. I've also placed an additional dependency .dll in the same directory, just as I have been doing during all of my development.
Some other things I've tried:
Using %PROGRAMFILES% instead of C:\Program Files (x86) as the value for the ActivatableClassAttribute in the manifest.
Using 'STA', 'MTA', and 'Both' as the threading models.
Added a trailing slash to the ActivatableClassAttribute value path.
Completely uninstalled everything and tried again from scratch.
Explicitly add an empty default constructor to the RfidDevice class.

WIX-Installer ServiceControl "sufficient privileges" error

Visual Studio 2015 RC
Wix v3.10.0.1726
I am creating a installer for a windows services. I've tested the service with InstallUtil and it runs fine. Unfortunately I'm having a bit of troubles with wix, here is the exact error -
"Service 'Service Name' failed to start. Verify that you have sufficient privileges to start system services."
Now I've narrowed down the issue to starting the service through WIX. If I forgo the ServiceControl tag and manually start it with services.msc it works fine.
From other questions it appears this error is a general catch error and occurs in a variety of situations. The most popular being if your service relies on assemblies installed to the GAC (Global Assembly Cache) which I am also unclear about. I never implicitly save anything to the GAC and my service simply calls a .cs file I wrote that is included in the project.
Any help would be greatly appreciated!
<Component Id="ProductComponent7">
<File Source="$(var.ServiceName.TargetPath)" KeyPath="yes" Vital="yes"/>
<ServiceInstall Id="ServiceName.exe"
Account="LocalSystem"
Arguments="-start"
Type="ownProcess"
Name="ServiceName.exe"
DisplayName="ServiceName Service"
Description="sdfg"
Start="auto"
Interactive="yes"
ErrorControl="critical" />
<ServiceControl Id="ServiceControl" Name="ServiceName" Start="install" />
</Component>
I've also tried a variety of different attributes in ServiceControl, I recently removed them all to try to make it as simple as possible.
If anyone has any insight that'd be great!
The issue appears to be that you've installed a service called ServiceName.exe and you're trying to start a serice called just ServiceName. The Name values need to match.
Correct, it's a generic error. You have to profile your service to understand why it won't start.
GAC is just one scenario. In that case it's because MSI doesn't publish assemblies to the GAC until after StartServices. A classic race condition that results in a missing dependency and error.
With the message box still up, run the EXE from the console. Do you get an errors? Do you get any errors in your application log? Find out why the service won't fix, resolve it and try again.
For me, the error was due to that Name attribute in the ServiceInstall tag was having a different name value from the one specified in the ServiceBase child class InitializeComponent() method.
Code updates:
In Product.wxs:
<ServiceInstall Id="ServiceInstaller"
Type="ownProcess"
Name="MyWindowsService"
DisplayName="$(var.ServiceDisplayName)"
Description="$(var.ServiceDiscription)"
Start="auto"
Account="LocalSystem"
ErrorControl="normal" />
In ServiceBase child class:
private void InitializeComponent()
{
components = new System.ComponentModel.Container();
this.ServiceName = "MyWindowsService";
}

TeamCity building with MsBuild and NuGet: "Unable to connect to the remote server"

I have setup my TeamCity to build using MsBuild a project that NuGet packages.
During the build, the following command to install packages is issued, but fails:
..\nuget.exe install "C:\TeamCity\buildAgent\work\811b6866c8757c46\Service\packages.config" -source "https://nuget.org/api/v2/" -RequireConsent -solutionDir "..\ "
Error:
Unable to connect to the remote server
with exit code 1.
Interesting to note is that when I run this exact same command on the cmd prompt (inside the same path), it succeeds without any errors.
This is what I have done so far:
Add a new Build Parameter under environment variables in TeamCity: env.EnableNuGetPackageRestore and set it to 'true'
Add a specific path to the package sources (https://nuget.org/api/v2/) inside the ..nuget\nuget.targets file (as described here)
To provide the additinal paths ways to supply a path:
Modified the nuget.config file inside the .nuget folder (..nuget\nuget.config)
Modified the nuget.config for the SYSTEM account that the build runner is executing under (C:\Windows\SysWOW64\config\systemprofile\AppData\Roaming\NuGet\nuget.Config) (as described here)
What I was thinking is that this has something to do with a roaming profile of the System user (that the build agents runs with) because it all works when build agent runs with my account. But the nuget.config is the same for both profiles, and I'm out of ideas. Maybe the System user doesn't have access to the Internet on WinServer2012R2? Maybe it needs additional permissions? Which ones?
Do you have any ideas of what to try?
The error turned out to be the setting for the ISA server we have on our network (the TMG client). By default this isn't set up for new (local) users and therefore the SYSTEM account didn't have access to the web.
I've set this up for a new local user (non-domain, with password that doesn't expire), added it to Administrators group and now it works just fine.

Categories