I do an automatic installation of the solution in SharePoint, I went along the simplest, as it seemed to me, ways:
I unpack PowerShell script, solution and .cmd from embedded resources in .exe,
I cause start of .cmd.

When you start it manually, everything works, when you call from the collected .exe, it does not see the SP snap-ins. Simplified the task before calling ONLY PowerShell from C # - and here is incomprehensible to me:

add-pssnapin microsoft.sharepoint.powershell
The snap-in microsoft.sharepoint.powershell Windows PowerShell is not installed on this computer.

At the same time, in the next PowerShell window, the same team quietly fulfills.
The user is the same (checked with commands), the profile (now empty) also leads to one file when trying to call notepad $ profile (there was a hope to add a snapin connection there, it did not help). What can be done?

If this is important, I start PS (and before that .cmd) through the process:

var process = new ProcessStartInfo(); process.FileName = "powershell.exe"; Process.Start(process).WaitForExit();

One team in different windows

  • Try running the installation as an administrator. - Monomax

1 answer 1

I decided. To match the PS behavior, you need to change the build target to CPU x64 in Visual Studio. Who cares why - I propose to go all this way in grains from all sources)), but the answer is exactly that.

  • It is not clear why you were surprised, initially the project in VS is created on the basis of x32, not x64 ... and SP is only x64, in rare cases, you can try to tie the service with x32, but not without hemorrhoids ... - Fox
  • Well, I was not used to changing "Any CPU" at all ... As for the knowledge that "SP is x64", the situation in my case looked something like this: "Why do I need to write an auto-installer? SharePoint? Project Not, why, heard something ... And why not push it in .cmd right away? Ah-ah ... Well, okay ... ":))) - Valery Pozdnev