Register DLL on a remote device for brokered component fails RRS feed

  • Question

  • Hi there,

    this question is related to: http://social.msdn.microsoft.com/Forums/windowsapps/en-US/ed421f21-2caa-4d47-a8f0-53929703eab6/print-in-kioskmode-with-brokered-component?forum=winappswithcsharp#01cf1fc4-4621-4a25-849e-b97ef0c862af

    It is Powershell / WindowsStore related but I don't know in wich forum I should put that question

    On my developer machine I succesfully created a silent print Service with a brokered component. But if I remote deploy / sideload / whatever the app on a remote machine (surface3 tablet) I'm failing to Register the proxyStub DLL with the regsvr32 command.

    No matter where I put the DLL it always says it "failed to load module" - but the path is correct, the files are there.

    I tried with elevated command prompt and also with elevated powershell (and tried both from system32 and syswow64). I also set the Execution Policies to Unrestricted and the scope to LocalMachine.

    If I try it that way on my developer machine, it Registers just fine. So I suspect some permission Problems or something else on the surface3 machine.

    Can someone shed any light on that behaviour?

    Oh and I also tried to put the dll directly in the system32 Folder with no success.

    • Edited by SW_Andy Tuesday, September 9, 2014 10:22 AM
    Tuesday, September 9, 2014 10:22 AM

All replies

  • Hi SW_Andy,

    Take a look if the blog can guide you: http://blogs.msdn.com/b/wsdevsol/archive/2014/04/14/cheat-sheet-for-using-brokered-windows-runtime-components-for-side-loaded-windows-store-apps.aspx

    The last part of blog introduce how to make configuration for the DLL files.


    MSDN Community Support

    Please remember to "Mark as Answer" the responses that resolved your issue. It is a common way to recognize those who have helped you, and makes it easier for other visitors to find the resolution later.

    Wednesday, September 10, 2014 5:52 AM
  • Hi there and sorry for the late reply. I was aware of that (and several other) guide... still registering the dll on the machine failed. My final solution was to install vs2013 on this machine, copied the solution over and build it from there - voila, the dlls got registered by vs2013. After that I deinstalled vs and pushed remote from my developer machine again. Since I haven't modified the dll itself again, there was no need for updating the registered dll.

    Clearly that wasn't the way meant to be, but under time pressure for releasing a brokered Project on only two devices it was the quickest solution... Either I made somewhere a silly error when trying registering the dll or there was some hickup with the systemconfiguration.

    Also I was a bit confused that some guides where referring to that line: icacls . /T /grant "ALL APPLICATION PACKAGES":RX and some wheren't.

    Thursday, September 18, 2014 8:22 AM
  • Is there some solution without installing Visual Studio in a tablet? 

    Monday, May 4, 2015 2:48 PM