We have a problem when scripting PowerDesigner on Windows Server 2012.
We don't have problems on Windows 10 and Windows 7 (we tried it on several machines).
We are starting PowerDesigner from PowerShell like this:
$PowerDesigner = New-Object -com powerdesigner.application
Add-Type -path “C:\Program Files (x86)\Sybase\PowerDesigner 16\Interop.PdCommon.dll”
Add-Type -path “C:\Program Files (x86)\Sybase\PowerDesigner 16\Add-ins\Microsoft SQL Server 2005 Analysis Service\Interop.PdPDM.dll”
On Windows Server 2012 R2 all properties of the $PowerDesigner object are set to $null.
If we try to set a property to some other value we get an error.
For example, the statement
$PowerDesigner.InteractiveMode = 1
fails with the following error:
Exception setting "InteractiveMode": "Library not registered. (Exception from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))"
The PowerDesigner version is 16.1.0.3637.
Related
I have a Win11 PC with Office365 and another Win11 PC with Office 2010
The PC with Office 2010 cannot create an Excel object in Powershell.
Here is my script:
$excel = New-Object -ComObject excel.application
$excel.Visible = $true
$workbook = $excel.Workbooks.Add(1)
$Worksheet = $workbook.worksheets.Item(1)
$ActiveWindow = $excel.ActiveWindow
Works fine on the Office365 machine, creates and opens a spreadsheet.
On the Office 2010 machine I get this error:
Exception setting "Visible": "Unable to cast COM object of type 'Microsoft.Office.Interop.Excel.ApplicationClass' to interface type
'Microsoft.Office.Interop.Excel._Application'. This operation failed because the QueryInterface call on the COM component for the
interface with IID '{000208D5-0000-0000-C000-000000000046}' failed due to the following error: Library not registered. (Exception
from HRESULT: 0x8002801D (TYPE_E_LIBNOTREGISTERED))."
At line:2 char:1
I am missing something obvious which has got me baffled.
Any ideas or suggestions.
The Office2010 PC has been repaired using a recovery USB to fix other issues. The trial version of Office365 was uninstalled and Office 2010 installed
While adding the PSSnapin for Microsoft.TeamFoundation.PowerShell using below command
Add-PSSnapin 'Microsoft.TeamFoundation.PowerShell'
getting this error
Add-PSSnapin : Cannot load Windows PowerShell snap-in
Microsoft.TeamFoundation.PowerShell because of the following error:
Unable to cast object of type
'Microsoft.TeamFoundation.PowerTools.PowerShell.TFPSSnapIn' to
type'System.Management.Automation.CustomPSSnapIn'.
Running this command Get-PSSnapin -Registered | fl * I am getting a proper result for installed Microsoft.TeamFoundation.PowerTools.PowerShell
Name : Microsoft.TeamFoundation.PowerShell
IsDefault : False
ApplicationBase : C:\Program Files (x86)\Microsoft Team Foundation Server 2015 Power Tools
AssemblyName : Microsoft.TeamFoundation.PowerTools.PowerShell, Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
ModuleName : C:\Program Files (x86)\Microsoft Team Foundation Server 2015 Power Tools\Microsoft.TeamFoundation.PowerTools.PowerShell.dll
PSVersion : 5.1
Version : 14.0.0.0
Types : {}
Formats : {}
Description : This is a PowerShell snap-in that includes the Team Foundation Server cmdlets.
Vendor : Microsoft Corporation
LogPipelineExecutionDetails : False
Verified while installing the Power Tools, I selected the option to install PowerShell Cmdlets
Also, I have verified the Microsoft.TeamFoundation.PowerTools.PowerShell.dll exist and it has a proper registry entry at Computer\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.TeamFoundation.PowerShell.
Tried repairing and reinstalling the TFS15 Power Tools, but nothing helped.
I am using windows 10 version 1809(OS build: 17763.55).
PowerShell 5.1
Major Minor Build Revision
----- ----- ----- --------
5 1 17763 1
Please make sure you have fully installed the TFS Powertools.
By default it doesn’t install the PowerShell CmdLets. If it is, just install it and then the issue will be gone.
Another possibility is that the PowerShell Snap-in is stored in the inconsistent registry with the OS version (32bit/64bit).
PowerTools installer is 32bit, on 64bit machine, it will write to
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\PowerShellSnapIns,
but not to
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns.
Reference this similar thread for details: TFS Power Tools 2008 Powershell Snapin won’t run in on 64-bit in Windows 2008 R2?
I'm trying to write a script to connect to TFS using powershell, however I'm stuck on the part of actually connecting
$credentialProvider = new-object Microsoft.TeamFoundation.Client.UICredentialsProvider
$collection = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection($uri, $credentialProvider)
It gives an error that says it cannot find the type
[ERROR] New-object : Cannot find type [ERROR]
[Microsoft.TeamFoundation.Client.UICredentialsProvider]: verify that
the [ERROR] assembly containing this type is loaded.
Well I tried to do this first, but it did not help
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Client")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.WorkItemTracking.Client")
[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.TeamFoundation.Build.Client")
I only have Visual Studio 2015 installed on my development environment. Is there some component that I'm missing that is a requirement for interfacing with TFS using powershell?
Furthermore I don't know where this script will be run from (it wont be from a development machine), presumably from a machine that has access to TFS server directly maybe using Team Explorer.
The Team Foundation Server Client Object Model used to be installed to the Global Assembly Cache when you installed Team Explorer 2013 or below. Because of that, they were always easy to load from any script.
With Team Explorer and Visual Studio 2015 and up, the packages are no longer registered globally. At the same time, Microsoft changed the license and made these assemblies distributable with your application and released a NuGet package to make distribution easier.
The proper way to handle scenarios where you need the TFS Client Object Model is to package them with your script or the download them on-demand using Nuget.
There are a number of packages that you may or may not need depending on what you are doing from your scripts:
Traditional Client Object Model:
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.Client/
https://www.nuget.org/packages/Microsoft.TeamFoundationServer.ExtendedClient/
New-style REST API object model:
https://www.nuget.org/packages/Microsoft.VisualStudio.Services.Client/
https://www.nuget.org/packages/Microsoft.VisualStudio.Services.InteractiveClient/
You can use this little snippet to fetch nuget.exe and the dependencies on the fly: https://stackoverflow.com/a/26421187/736079 or use the install-package that was introduced in powershell v5.
Note: If you're updating or creating new scripts, it's recommended to switch to the new-style REST API's and the object model that goes along with that.
Here is what I used to pull in the dll's for 2013,2015 tfs
function Connect-ToTfs
{
Param([string] $Collectionurl)
#the collection url will be cast as a uri to the getteamproject collection.
Write-Verbose $Collectionurl
if ($CollectionUrl -ne '')
{
#if collection is passed then use it and select all projects
$tfs = [Microsoft.TeamFoundation.Client.TfsTeamProjectCollectionFactory]::GetTeamProjectCollection([uri]$CollectionUrl)
}
else
{
#if no collection specified, open project picker to select it via gui
$picker = New-Object Microsoft.TeamFoundation.Client.TeamProjectPicker([Microsoft.TeamFoundation.Client.TeamProjectPickerMode]::NoProject, $false)
$dialogResult = $picker.ShowDialog()
if ($dialogResult -ne 'OK')
{
#exit
}
$tfs = $picker.SelectedTeamProjectCollection
}
$tfs
}
function Invoke-VisualStudioDlls
{
if (Test-Path 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer')
{
Write-Verbose "importing Visual Studio 2015 Dll's"
Invoke-Visual15StudioDlls
}
elseif (Test-Path 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0')
{
Write-Verbose "importing Visual Studio 2013 Dll's"
Invoke-Visual13StudioDlls
}
}
function Invoke-Visual15StudioDlls
{
$visualStudiopath = 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer'
#$visualStudiopath45 = 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer'
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.VersionControl.Client.dll"
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.Common.dll"
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.WorkItemTracking.Client.dll"
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.Client.dll"
Add-type -path "$visualStudiopath\Microsoft.TeamFoundation.ProjectManagement.dll"
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.Build.Common.dll"
}
function Invoke-Visual13StudioDlls
{
$visualStudiopath = 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\IDE\ReferenceAssemblies\v2.0'
$visualStudiopath45 = 'C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\ide\ReferenceAssemblies\v4.5'
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.VersionControl.Client.dll"
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.Common.dll"
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.WorkItemTracking.Client.dll"
Add-Type -Path "$visualStudiopath\Microsoft.TeamFoundation.Client.dll"
Add-type -path "$visualStudiopath45\Microsoft.TeamFoundation.ProjectManagement.dll"
}
In Visual Studio 2015, the object model client libraries are removed from GAC. In order to load them you need to point the Add-Type cmdlet to a path, for example:
Add-Type -Path "C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer\Microsoft.TeamFoundation.Client.dll"
Otherwise, you could install package from Nuget as #Jessehouwing mentioned.
I am trying to access the document of an internet explorer com object with windows 2012. The code works great in windows 2008 but as soon as I try to run it on windows 2012 (fresh install, tried on more than one server), the same code stops working. In other words, $ie.document.documentHtml returns as null.
Below is the code:
$ie = new-object -com "InternetExplorer.Application"
$ie.navigate2("http://www.example.com/")
while($ie.busy) {start-sleep 1}
$ie.document.documentHtml.innerhtml
Has the interexplorer com object changed in windows 2012? and if yes, how do I do I retrieve the document contents in windows 2012?
Thanks in advance
edit: Added a bounty to sweeten things up. Invoke-WebRequest is nice but it works only on windows 2012 but I need to use internet explorer and have it work both on windows 2008 and windows 2012. I have read somewhere that installing microsoft office solves the issue. It is not an option either.
edit2: as I need to remotely invoke the script on multiple windows server (both 2008 and 2012), I would prefer not to copy files manually
It's a know bug: http://connect.microsoft.com/PowerShell/feedback/details/764756/powershell-v3-internetexplorer-application-issue
An extract from the workaround:
So, here's a workaround:
Copy Microsoft.html.dll from a location where it is installed (eg: from C:\Program Files(x86)\Microsoft.NET\Primary Interop Assemblies to your script's location (can be a network drive)
Use the Load-Assembly.ps1 script (code provided below and at: http://sdrv.ms/U6j7Wn) to load the assembly types in memory
eg: .\Load-Assembly.ps1 -Path .\microsoft.mshtml.dll
Then proceed as usual to create the IE object etc. Warning: when dealing with the write() and writeln() methods use the backward compatible methods: IHTMLDocument2_write() and IHTMLDocument2_writeln().
$ie.document.documentHtml.innerhtml
The bigger question is how this ever could have worked. The Document property returns a reference to the IHTMLDocument interface, it does not have a "documentHtml" property. It is never that clear what you might get back when you use late binding as was done in this code. There is an old documentHtml property supported by the DHTML Editing control, that has been firmly put to the pasture. Admittedly rather a wild guess.
Anyhoo, correct syntax is to use, say, the body property:
$ie = new-object -com "InternetExplorer.Application"
$ie.navigate2("http://www.example.com/")
while($ie.busy) {start-sleep 1}
$txt = $ie.document.body.innerhtml
Write-Output $txt
If you still have problems, Powershell does treat null references rather undiagnosably, then try running this C# code on the machine. Ought to give you a better message:
using System;
class Program {
static void Main(string[] args) {
try {
var comType = Type.GetTypeFromProgID("InternetExplorer.Application");
dynamic browser = Activator.CreateInstance(comType);
browser.Navigate2("http://example.com");
while (browser.Busy) System.Threading.Thread.Sleep(1);
dynamic doc = browser.Document;
Console.WriteLine(doc.Body.InnerHtml);
}
catch (Exception ex) {
Console.WriteLine(ex.ToString());
}
Console.ReadLine();
}
}
As far as I can tell, on Windows Server 2012 to get the full html of a page:
$ie.document.documentElement.outerhtml
There is also an innerhtml property on the documentElement, which strips off the root <html> element.
Of course, if all you want to do is get the raw markup, consider using Invoke-WebRequest:
$doc = Invoke-WebRequest 'http://www.example.com'
$doc.Content
Get any PC with Office installed and copy Microsoft.mshtml.dll to your script location.
c:\program files (x86)\Microsoft.net\primary interop assemblies\Microsoft.mshtml.dll
add-Type -Path Microsoft.mshtml.dll
Script works.
I have installed the PowerShellPack on a Server 2008 R2 machine, but am unable to use the PSImageTools module. All image operations yield the error New-Object : Cannot load COM type Wia.ImageFile. I have tried installing the same package on my Windows 7 laptop, and there it works.
I figure this must be because of missing Dll:s on the server, but even copying the wia*.dll files to System32 from the laptop (there are no corresponding files already in place) helps. It is not possible to register the dlls (regsvr32 wiaaut.dll, for instance), that is replied to with "The file failed to load".
So, has anybody successfully used Wia on Windows Server 2008? We're going to run a scheduled powershell script to update the outlook image of our users, so it needs to be able to run on the server.
I get the same error on Windows Server 2008 x64. Tried both x64 and x86 version of PowerShell v2.
As an alternative you might be able to use System.Drawing.Image. Depends on what your script needs to do. Perhaps post some example code.
http://msdn.microsoft.com/en-us/library/system.drawing.image.aspx
Add-Type -AssemblyName System.Drawing
$image = [System.Drawing.Image]::FromFile("C:\pic.bmp")
EDIT: Here's how you can change an image's dimensions:
$pixWidth = 90
$pixHeight = 90
$image2 = New-Object System.Drawing.Bitmap -ArgumentList $image, $pixWidth, $pixHeight
$image2.Save('C:\new_pic.bmp', [System.Drawing.Imaging.ImageFormat]::Bmp)
Found this article after quite a bit of searching:
http://kb.winzip.com/kb/entry/207/
Basically, you need to enable and set to Automatic the "Windows Image Acquisition" service in Windows 2003, or in Windows 2008, install the Desktop Experience feature first, then enable the "Windows Image Acquisition" service and set to Automatic.