search

microsoft / vssetup.powershell

PowerShell module to interact with Visual Studio Setup
MIT License
227 stars 40 forks source link

Can't import VSSetup module #43

Closed eeevans closed 6 years ago

eeevans commented 6 years ago

version 2.0.1.32208

import-module vssetup import-module : The following error occurred while loading the extended type data file: Error in TypeData "Microsoft.VisualStudio.Setup.Instance": Type "Microsoft.VisualStudio.Setup.PowerShell.InstanceAdapter" should be a PSPropertyAdapter. At line:1 char:1

heaths commented 6 years ago

It is a PSPropertyAdapter. I haven't had this problem and use the module frequently in both Windows PowerShell and PowerShell Core. Please update to a newer version and see if it repros. IF it does, please also include the $PSVersionTable from whatever PowerShell instance you're using as it could be a bug on their side.

eeevans commented 6 years ago

when I install any of the PreRelease versions they don't contain the files Microsoft.VisualStudio.Setup.Configuration.Interop.dll Microsoft.VisualStudio.Setup.PowerShell.dll

If I download the zip file from the project site, the Interop dll is from 6/23/2017 so not sure if that is correct but it then gives the same error.

Name Value

PSVersion 5.1.17134.112 PSEdition Desktop PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} BuildVersion 10.0.17134.112 CLRVersion 4.0.30319.42000 WSManStackVersion 3.0 PSRemotingProtocolVersion 2.3 SerializationVersion 1.1.0.1

heaths commented 6 years ago

The interop DLL rarely needs to be updated, but I do see the prerelease versions are missing the DLLs. I'll take a look. But 2.0.1.32208 certainly does contain these DLLs. That is the version you reported originally. Could you clarify which module version you're reporting?

eeevans commented 6 years ago

VSSetup 2.0.1.32208 - has the DLLs - gives the error All 3 prerelease complain about the missing DLLs; when I download the zip files from github and copy the files there manually, they also give the error. This is on 2 different developer machines with Windows 10

heaths commented 6 years ago

The missing DLLs I can repro. In fact, I'm just about ready to push a commit and prep a release. But you're the first to report the other issue after several hundred thousand downloads and untold more times the module has been loaded. The InstanceAdapter is definitely a PSPropertyAdapter so I'm not sure why PowerShell is complaining.

Can you run the following and paste the result (replace the error record index with whatever is appropriate, but the following should work as-is):

import-module vssetup
$Error[0].Exception | select * | clip
eeevans commented 6 years ago

ErrorRecord : The following error occurred while loading the extended type data file: Error in TypeData "Microsoft.VisualStudio.Setup.Instance": Type "Microsoft.VisualStudio.Setup.PowerShell.InstanceAdapter" should be a PSPropertyAdapter.

WasThrownFromThrowStatement : False Message : The following error occurred while loading the extended type data file: Error in TypeData "Microsoft.VisualStudio.Setup.Instance": Type "Microsoft.VisualStudio.Setup.PowerShell.InstanceAdapter" should be a PSPropertyAdapter.

Data : {} InnerException : TargetSite : Void ThrowTypeOrFormatErrors(System.String, System.String, System.String) StackTrace : at System.Management.Automation.Runspaces.InitialSessionState.ThrowTypeOrForm atErrors(String resourceString, String errorMsg, String errorId) at System.Management.Automation.Runspaces.InitialSessionState.UpdateTypes(Exe cutionContext context, Boolean updateOnly) at System.Management.Automation.Runspaces.InitialSessionState.Bind_UpdateType s(ExecutionContext context, Boolean updateOnly) at System.Management.Automation.Runspaces.InitialSessionState.Bind(ExecutionC ontext context, Boolean updateOnly, PSModuleInfo module, Boolean noClobber, Boolean local) at System.Management.Automation.Runspaces.InitialSessionState.Bind(ExecutionC ontext context, Boolean updateOnly) at Microsoft.PowerShell.Commands.ModuleCmdletBase.LoadModuleManifest(String moduleManifestPath, ExternalScriptInfo manifestScriptInfo, Hashtable data, Hashtable localizedData, ManifestProcessingFlags manifestProcessingFlags, Version minimumVersion, Version maximumVersion, Version requiredVersion, Nullable`1 requiredModuleGuid, ImportModuleOptions& options, Boolean& containedErrors) HelpLink : Source : System.Management.Automation HResult : -2146233087

heaths commented 6 years ago

That's a different error. Please type $Error first, figure out the index of the original error you reported, and use that (the stack - the array - grows "down"). For example, you might need $Error[1]. You can examine it before you paste it here and make sure the error message represents the issue you reported.

eeevans commented 6 years ago

sorry, I had uninstalled and downloaded the packages to look for the files and forgot to install again before running the commands...I updated the error.

heaths commented 6 years ago

Can you run process monitor (https://sysinternals.com, procmon) and fuslogvw.exe (part of the Windows / .NET SDK). From the former, is the DLL being loaded fully? From the latter, do you see any fusion errors reported?

Or are you otherwise aware of any policies that prevent unsigned files (either Authenticode or strong name, though I'm not aware of any policy settings that prevent the loading of non-strong named-signed files) from being loaded? I don't see an inner exception (I was hoping maybe to see a TypeLoadException or something like that, but no) so I doubt that's the case.

But I'm afraid I just can't repro this nor has it been reported before, and I know quite a few people who use it regularly besides myself. It's likely a difference in the machines' configuration (my home machine loads this fine and is pretty standard with not a lot of extra non-Store software - pretty much VS, VSCode, git, gpg, vim, and a few other basics).

eeevans commented 6 years ago

Assembly Binder Log Entry (6/21/2018 @ 5:29:01 PM)

The operation failed. Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under executable C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe --- A detailed error log follows.

=== Pre-bind state information === LOG: DisplayName = Microsoft.VisualStudio.Setup.PowerShell (Partial) WRN: Partial binding information was supplied for an assembly: WRN: Assembly Name: Microsoft.VisualStudio.Setup.PowerShell | Domain ID: 1 WRN: A partial bind occurs when only part of the assembly display name is provided. WRN: This might result in the binder loading an incorrect assembly. WRN: It is recommended to provide a fully specified textual identity for the assembly, WRN: that consists of the simple name, version, culture, and public key token. WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue. LOG: Appbase = file:///C:/Windows/System32/WindowsPowerShell/v1.0/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = powershell.exe Calling assembly : (Unknown).

LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.Config LOG: Using host configuration file: LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: The same bind was seen before, and was failed with hr = 0x80070002. ERR: Unrecoverable error occurred during pre-download check (hr = 0x80070002).

eeevans commented 6 years ago

Starting from fresh powershell: Assembly Binder Log Entry (6/21/2018 @ 5:43:37 PM)

The operation failed. Bind result: hr = 0x80070002. The system cannot find the file specified.

Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework64\v4.0.30319\clr.dll Running under executable C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe --- A detailed error log follows.

=== Pre-bind state information === LOG: DisplayName = Microsoft.VisualStudio.Setup.PowerShell (Partial) WRN: Partial binding information was supplied for an assembly: WRN: Assembly Name: Microsoft.VisualStudio.Setup.PowerShell | Domain ID: 1 WRN: A partial bind occurs when only part of the assembly display name is provided. WRN: This might result in the binder loading an incorrect assembly. WRN: It is recommended to provide a fully specified textual identity for the assembly, WRN: that consists of the simple name, version, culture, and public key token. WRN: See whitepaper http://go.microsoft.com/fwlink/?LinkId=109270 for more information and common solutions to this issue. LOG: Appbase = file:///C:/Windows/System32/WindowsPowerShell/v1.0/ LOG: Initial PrivatePath = NULL LOG: Dynamic Base = NULL LOG: Cache Base = NULL LOG: AppName = powershell.exe Calling assembly : (Unknown).

LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe.Config LOG: Using host configuration file: LOG: Using machine configuration file from C:\Windows\Microsoft.NET\Framework64\v4.0.30319\config\machine.config. LOG: Policy not being applied to reference at this time (private, custom, partial, or location-based assembly bind). LOG: Attempting download of new URL file:///C:/Windows/System32/WindowsPowerShell/v1.0/Microsoft.VisualStudio.Setup.PowerShell.DLL. LOG: Attempting download of new URL file:///C:/Windows/System32/WindowsPowerShell/v1.0/Microsoft.VisualStudio.Setup.PowerShell/Microsoft.VisualStudio.Setup.PowerShell.DLL. LOG: Attempting download of new URL file:///C:/Windows/System32/WindowsPowerShell/v1.0/Microsoft.VisualStudio.Setup.PowerShell.EXE. LOG: Attempting download of new URL file:///C:/Windows/System32/WindowsPowerShell/v1.0/Microsoft.VisualStudio.Setup.PowerShell/Microsoft.VisualStudio.Setup.PowerShell.EXE. LOG: All probing URLs attempted and failed.

heaths commented 6 years ago
  1. In what context (user or machine/all users) did you install the module? Or is it in a custom path? What does the directory structure for that module look like?
  2. Do you have this assembly in the GAC (C:\Windows\assembly)?
  3. What versions of PackageManagement and PowerShellGet do you have: get-module -list packagemanagement, powershellget

Running Process Monitor and examining what files PowerShell is trying to open would really help.

eeevans commented 6 years ago

I understand it's probably something with my environment. I often have Path issues after installing SQL 2K8 R2, 2012, 2014, 2016 at the same time...each adds 4 or 5 paths to the Path env variable and gives me grief. I appreciate any help or pointers but understand this is not really an issue with the package.

The context for all the packages is Machine...I'm not a big fan of User.

C:\Users\ed.evans> get-module -list packagemanagement, powershellget

Directory: C:\Program Files\WindowsPowerShell\Modules

ModuleType Version Name ExportedCommands

Script 1.1.7.2 PackageManagement {Find-Package, Get-Package, Get-PackageProvider, ... Binary 1.0.0.1 PackageManagement {Find-Package, Get-Package, Get-PackageProvider, ... Script 1.6.5 PowerShellGet {Find-Command, Find-DSCResource, Find-Module, Fin... Script 1.0.0.1 PowerShellGet {Install-Module, Find-Module, Save-Module, Update...

Procmon logfile here https://gist.github.com/eeevans/22450c36cbf7a6a41145354f0645e11f

heaths commented 6 years ago

It's definitely being found:

"9:20:49.4941699 AM","powershell.exe","26452","CloseFile","C:\Program Files\WindowsPowerShell\Modules\VSSetup\2.0.1.32208\Microsoft.VisualStudio.Setup.PowerShell.dll","SUCCESS",""

Both modules above are pretty old. Try updating them first. You may actually need to use install-module rather than update-module because those appear to be the in-box versions that don't have the metadata to upgrade (i.e. pre-installed):

install-module -force packagemanagement, powershellget

Then try to reload the VSSetup module. FWIW, I was still able to load this with older versions of those packages as well.

eeevans commented 6 years ago

So, I installed Powershell Core latest and VSSetup work fine in there so it is definitely something wrong in the normal Powershell. I ran sfc /scannow to check for corrupt system files and that didn't find anything.

As for the versions of PackageManagement and PowershellGet they are 1.1.7.2 and 1.6.5 respectively which is in the output above. They also have 1.0.0.1 but the formatting got screwed up in pasting into github comment.

heaths commented 6 years ago

My only other suggestion is to remove the module and try re-installing it. I'm really not sure what else you could try, but it's pretty clear this isn't the module so I'm resolving as external.

I've sent an email internally to the PowerShell team but no closer to an answer. If the above suggestion doesn't fix it, you might try comparing procmon or even fusion logs (logging all bindings - even successful ones) to see if some policy on the machine is causing this problem. I'll post back if I hear anything new.