Vista - WCF calling the powershell

Hi, i have a question.

I developt a PSCommandLet and install it ob a PC. When i call it from the PC
all works fine.

Now i write a WCF Service with some methods and they methods call some of my
powershell CmdLets. When i now run a client on a other PC and call the WCF
Service methods i always get an exception that my powershell-snap-in is not
installed on the PC. Why it works local but not if an client call the WCF
Service and the service call the PS???

Here my code:

RunspaceConfiguration config = RunspaceConfiguration.Create();


Runspace runspace = RunspaceFactory.CreateRunspace();

runspace.Open();

PSSnapInException ex = new PSSnapInException();

runspace.RunspaceConfiguration.AddPSSnapIn("SunvoltEnergyStudioPowerShell",
out ex);

Collection<Project> projects = new Collection<Project>();
Pipeline getProjectsPipeline = runspace.CreatePipeline();
getProjectsPipeline.Commands.Add(new Command("Get-Projects"));
Collection<PSObject> results = getProjectsPipeline.Invoke();

Hi Bob,
sorry if i not clear.

PC A -> CmdLet -> WCF
PC B -> Client App.

PC B call the WCF Service on PC A
The PC A called the CmDLet and returnd a Result

The exception is thrown on AddPSSnapIn call.
On PC A i tested the CmdLet manuall, it is installed and work fine.

But if PC B called the WCF and the WCF methode try to add the Snapin it fail.

"Bob Landau" wrote:

Steffen,

I've never created a snapin, about the time I started getting interested in
Powershell v2 was released as a CTP and modules at least to my understanding
have replaced snapin's any case thats the route I went.

Perhaps someone that has a better understanding of snapins can help.

Here is what I understand

PC B : Client-App => PC A: WFC service (Add's and uses your snapin)

The WFC service is most likely running under the credentials of
"NetworkService" and I wouldn't recomend changing it _except_ possible to
verify if that's the problem.

This account is limited on purpose I suspect the reason for the exception
(BTW what is the exception being thrown?) is because AddSnapin requires more
priviledges than this account is capabile of.

If this does turn out to be the issue you will need to add the snapin by
impersonating an account that has these priviledges and then revert back to
the process account since you will want this service running with the mimimal
priviledges that are required.

"Steffen Mangold" wrote:

> I've never created a snapin, about the time I started getting interestedYes, you've got it right... v1 snapins => v2 modules. Now that being said,
v2 modules provide loads of extra features like they can be regular scripts
and don't need to be compiled like snapins did (who had to be written in
..NET).

Marco

Yes, but this makes no differents to my problem.

Can nobody help me with that?

"Marco Shaw [MVP]" wrote:

I play i bit with this case and found that it is not possible to a a snapin
form a service. Because always exception "not installed on machine". Seems to
be a privileg problem. But do i need admin rights to add a snapin???

No. You need admin rights to INSTALL a snapin originally (because you
have to 'register' it), but not to add it to a powershell session.

This, incidentally, is why loading them as "modules" in v2 is cool: they
don't have to be 'registered' first, so you don't have to be admin to
install a module (which can be just a snapin).


You're sure the snapin has been installed and can be loaded right?
You're sure that's the full name of the snapin?
Have you tried printing out the errors:

runspace.RunspaceConfiguration.AddPSSnapIn(
"SunvoltEnergyStudioPowerShell", out ex);

if (ex!= null)
{
System.Console.Write(ex.Message);
return;
}

I'm afraid I don't have many ideas, if the snapin is registered, it
should show up and be addable for all users, as far as I know.

--
Joel


Steffen Mangold wrote:

The credentials used for services such as NetworkService is truely a
different animal. They have far less credentials than the normal user for
security reasons.

I had mentioned it briefly above, based on the difficulty your having I
believe you'll need to impersonate a user account prior to calling AddSnapin.

Steffen if you search the web for Powershell and ASP.NET I'm think you an
answer to your question.

Here is one possible
http://support.microsoft.com/default.aspx/kb/306158

"Joel Bennett [MVP]" wrote:

I run the Server on a x64 OS. And i find a other bug i think that can have
the same reason. The WCF Service is x32 compiled, normally (such a normal
service) if a app. is complied in x32, if it access the Regedit it goes to
the WOW64 nodes. All my services works so, but if i call a WCF method from
remote and go to regedit if goes to the x64 nodes. That should not happen
normally!! So it seems there is some problem in the running WCF service (the
WCF service is hosted by a normal x32 WinService)

"Bob Landau" wrote:

Seems to me like your too close to the solution. One of the two issues are
likely what is causing your problem.

1) Registered the snapin (and assume it will work as both a x64 and x32 app)
It will not. You must register the application using both

2) A 32 bit DLL won't fit in a x64 host and visa-versa. Why are you assuming
that this DLL is 32 bit? This means you DLL must be 64 bit based on your
detective work.

This is managed code correct? By default when its GIT'ed the runtime will
pick the native environment over the emulated which for you is 64bit.

So you can either force the runtime to GIT a 32 bit DLL (there's a program
option for this).
btw I ran into the same problem once when I tried to load a 32 bit COM DLL
in managed code. your not the only one that has been bitten by this

Or you can register this snapin for both 32 bit and 64 bit. Prior to trying
anything else verify that from both the 32 and 64 bit Powershell shell you
can call Add-PSSnapin.

If even after this you are still having problems the issue may still be want
I mentioned originally.

"Steffen Mangold" wrote: