Remove project from solution via Package Manager Console - visual-studio

I am trying to use powershell within the Package Manager Console to script the removal of a project from a solution and I am having a surprisingly hard time.
I can easily add a project by
PM> $dte.Solution.AddFromFile("C:\Dev\Project1.csproj")
Now I want to be remove a project and can't get anything to work.
I have tried a number of things including:
PM> $project1 = Get-Project "Project1Name"
PM> $dte.Solution.Remove($project1)>
Cannot convert argument "0", with value: "System.__ComObject", for "Remove" to
type "EnvDTE.Project": "Cannot convert the "System.__ComObject" value of type
"System.__ComObject#{866311e6-c887-4143-9833-645f5b93f6f1}" to type
"EnvDTE.Project"."
PM> $project = Get-Interface $project1 ([EnvDTE.Project])
PM> $dte.Solution.Remove($project)
Cannot convert argument "0", with value: "System.__ComObject", for "Remove" to
type "EnvDTE.Project": "Cannot convert the "System.__ComObject" value of type
"NuGetConsole.Host.PowerShell.Implementation.PSTypeWrapper" to type
"EnvDTE.Project"."
PM> $project = [EnvDTE.Project] ($project1)
Cannot convert the "System.__ComObject" value of type
"System.__ComObject#{866311e6-c887-4143-9833-645f5b93f6f1}" to type
"EnvDTE.Project".
PM> $solution2 = Get-Interface $dte.Solution ([EnvDTE80.Solution2])
PM> $solution2.Remove($project1)
Exception calling "Remove" with "1" argument(s): "Exception calling
"InvokeMethod" with "3" argument(s): "Object must implement IConvertible.""
PM> $dte2 = Get-Interface $dte ([EnvDTE80.DTE2])
PM> $dte2.Solution.Remove($project)
Method invocation failed because [System.Object[]] doesn't contain a method
named 'Remove'.
I have tried other combinations, but I am clearly spinning my wheels. I appreciate any suggestions.

Right, I know I'm late to the party but I've just been tackling this same issue for an internal NuGet package we've been writing, and I think I've found how to do it.
Indeed Microsoft have (helpfully) left the Delete method unimplemented, and as we have both found, attempting to call the Remove method on the Solution2 interface throws an exciting myriad of errors depending on context!
However what I have found is that directly invoking the Remove method defined in SolutionClass does actually work (despite its being documented by Microsoft as internal use only. But hey, when every other option is exhausted...). The only catch is that the runtime binder also sometimes seems to fail to resolve the method overload, producing the error:
No overload for method 'Remove' takes 1 arguments
All of which means that it's time to get our reflection crayons out! The code looks like this:
$removeMethod = [EnvDTE.SolutionClass].GetMethod("Remove");
$solution = $dte.Solution;
$toremove = ($solution.Projects | where ProjectName -eq "<whatever>");
$removeMethod.Invoke($solution, #($toremove));
After a day of various iterations (many closely resembling those in the question) and varying degrees of success (depending on whether I was executing inside the package manager, from inside the install script or within a debugger), the above is what I have found to be most reliable.
One thing to note is that because the reflected method is defined in EnvDTE.SolutionClass, passing it a EnvDTE._Solution or EnvDTE80.Solution2 throws a Type mismatch error, so unfortunately you cannot obtain your $solution object by the Get-Interface cmdlet (which is usually my preferred method). Doing the cast to [EnvDTE.SolutionClass] wherever possible is obviously preferable, but again I've found varying degrees of success in doing so. Hence the slightly sloppy $solution = $dte.Solution above.
Hope this is useful to someone else!

Looks like it is "Delete" instead of "Remove". See this MSDN article
Project prj = dte.Solution.Projects.Item(1);
prj.Delete();

Related

convert object from one assembly to another cli c++

I have an multi Module Project. Here we are passing System::Object^ from one exe to code from another DLL.
When I am trying to convert that Object to its type(Here we have the same definition) in DLL, I am getting the below error...
[A] can not be cast to [B]; A originates from one assembly , b from another
I tried through some documents but could not crack through.
Both the below code giving that conversion error
LocalClassType ^x1 = LocalClassType (x);
LocalClassType ^x2 = cli::safe_cast<LocalClassType ^>(x)
Can anyone please suggest or guide me through the document where I can convert correctly.
I was able to resolve the issue, and cast it using static_cast
LocalClassType ^x2 = static_cast<LocalClassType ^>(x)

PyCharm debugger doesn't show objects' content: "Unable to get repr for <type 'list>"

Debugging with PyCharm (happens on multiple versions) I'm unable to correctly view some lists and dictionaries (other are presented correctly).
In the view window the object's name is presented with the message:
{list} Unable to get repr for <type 'list>
or
{dict} Unable to get repr for <type 'dict'>
An update:
In one of my attempts, I received the following message from the debugger (presented instead of the value of one of the list variable):
Unable to display children:Error resolving variables Traceback (most
recent call last): File "/Applications/PyCharm
CE.app/Contents/helpers/pydev/_pydevd_bundle/pydevd_comm.py", line
1004, in do_it
_typeName, valDict = pydevd_vars.resolve_compound_variable(self.thread_id, self.frame_id,
self.scope, self.attributes) TypeError: 'NoneType' object is not
iterable
I'll appreciate any idea as for what may cause this behavior?
Thanks!
It turned out the problem is due to usage of rpyc.py: The process I was debugging was called through rpyc and while I was debugging it, the calling process received a timeout on the rpyc connection.
I think that this caused variables, passed through rpc to lose integrity so the debugger couldn't present them correctly.
The solution was to downgrade rpyc.py to version 3.3.0 (I was on 3.4.2).
My colleague, Nurit Izraelov, correctly suggested the rpyc.py version may be the blame.
Thanks all!
It happened to me sometimes and what caused the behaviour was that some MyClass triggered an exception on its str method.
In such a case, PyCharm debugger only showed
some_object = {MyClass} Unable to get repr for <class 'my_app.models.MyClass'>
So what I did to confirm the origin was to watch repr(some_object) in the Watches section of the debugger. And there it gave me an explicit error message:
{TypeError}%d format: a number is required, not NoneType
Which helped me trace back to the origin.
I appreciate this is not a generic answer, but just a complement to Fabio's.
Probably some custom class of yours has a bad __repr__ or __str__ in it and the debugger is unable to print it.
You can probably use a shell at that point to know which elements are actually inside such a dict or list (and see which object has the faulty __repr__ or __str__).
Extending the scope of the problem rather than adding an answer - all the other suggestions are what I do normally to get this working.
Could it be a race condition?
For me it appears to be something weird. In the Variables pane I can see correct representation for theObject, repr(theObject) and even [theObject] but if I set a variable in my code thus a = theObject or b = [theObject] then I get the "Unable to get repr for <class 'list'>" message.
theObject in this case is an instance of a subclassed D lang struct wrapped with autowrap.

Error type go lang

Is error type in Go "Error" or "error"? It bugged me that in the Tour it is with small first letter so I looked around and found here with small e yet here in source code it is with big capital letter.
Also how can it be without big capital letter yet still visible outside of package?
Just started learning Go so I might have missed something basic, thanks.
error is the type, lowercase. Just like with int and string it doesn't need to be visible as it is built-in to Go:
A good blog post on error handling
The runtime package you're referring to has an Error interface. The type there is an interface not error:
Package runtime
type Error interface {
error
// RuntimeError is a no-op function but
// serves to distinguish types that are run time
// errors from ordinary errors: a type is a
// run time error if it has a RuntimeError method.
RuntimeError()
}
The Error interface identifies a run time error.

Why is the (PyQt5) QWidget not being added to the QBoxLayout

Right so essentially I am creating a user interface and have attempted to add a QtWidgets.QLineEdit to a QVBoxLayout as well as a QtWidgets.QLabel to a different QVBoxLayout. Unfortunately it is not working and throwing up an error:
in build_gui_adddata_device
self.labellayout.addWidget(self.labelsupplierid)
TypeError: QBoxLayout.addwidget(QWidget; int stretch=0, Qt.Alignment alignment=0): first argument of unbound = method must have type QBoxLayout
I have defined labellayout as thus:
print("e")
self.labellayout = QtWidgets.QVBoxLayout
"e" was printed, which is how I know that there is no issue with the definition of the layout itself.
Just for reference this is the QtWidget I was trying to add:
print("f")
self.labelsupplierid = QtWidgets.QLabel("Supplier ID: ")
Again "f" was printed
This is the line that is causing the problem:
print("i")
self.labellayout.addWidget(self.labelsupplierid)
I don't understand why my code isn't working, I am honestly perplexed. My syntax seems to be correct and I have made other build_gui functions that have executed exactly the same type of code (with different widgets, might I add) that have been successful.
Please can someone enlighten me. Many Thanks.

Issues in installing COM + Component using PowerShell script

I'm trying to install COM + Component using powershell. But I'm getting following error.
Unable to find type [some.dll]. Make sure that the assembly that contains this
type is loaded.
+ $comAdmin.InstallComponent("test", [some.dll]);
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (COMITSServer.dll:TypeName) [], Runtime
Exception
+ FullyQualifiedErrorId : TypeNotFound
and here is my powershell script:
Install COM + Components
$comAdmin = New-Object -comobject COMAdmin.COMAdminCatalog;
$comAdmin.InstallComponent("some", [some.dll]);
#if an exception occurs in installing COM+ then display the message below
if (!$?)
{
Write-Host "Unable to Install the COM+ Component. Aborting..."
exit -1
}
My powershell version is 4.0
Can someone please help me on this.
Thank you.
Square brackets in PowerShell indicate a type, like [string] or [int32] or [System.Array] or [System.Math]. The error message is complaining because you're telling PowerShell that COMITSServer.dll is a registered and loaded data type.
Additionally, the InstallComponent method of COMAdminCatalog appears to me to have four arguments, not two. You should be able to confirm that by looking at the definition, but I don't know if v2.0 supports doing it like this:
PS U:\> $comAdmin = New-Object -comobject COMAdmin.COMAdminCatalog
PS U:\> $comAdmin | gm | where { $_.Name -eq 'InstallComponent' }
TypeName: System.__ComObject#{790c6e0b-9194-4cc9-9426-a48a63185696}
Name MemberType Definition
---- ---------- ----------
InstallComponent Method void InstallComponent (string, string, string, string)
As such, I would try this:
$comAdmin.InstallComponent("ITSServerOO2", "COMITSServer.dll", "", "");
That appears to be how the VB code here calls the same method:
' Open a session with the catalog.
' Instantiate a COMAdminCatalog object.
Dim objCatalog As COMAdminCatalog
Set objCatalog = CreateObject("COMAdmin.COMAdminCatalog")
[...]
' Install components into the application.
' Use the InstallComponent method on COMAdminCatalog.
' In this case, the last two parameters are passed as empty strings.
objCatalog.InstallComponent "MyHomeZoo","MyZoo.DLL","",""
Here is the class definition of that function, I believe, athough I'm not familiar enough with COM+ to know if COMAdminCatalog and ICOMAdminCatalog are the same.
This is an answer to the question about the 0x80110401 HRESULT. (BTW, follow up questions should be answered in a new post on SO, not in the comments of an existing question). This allows other people to find answers when they have the same question.
Documentation for ICOMAdminCatalog::InstallComponent. As the documentation explains the first parameter is GUID, the second is the DLL being registered. The third parameter (typelib) and fourth (proxy stub DLL) are optional and can be specified as an empty string.
"test" is not a valid GUID. Note that a GUID is a distinct .NET type (System.Guid). However the documentation calls for a BSTR which would translate into a System.String. To get a new GUID as a string use this: [Guid]::NewGuid().toString().
Note that GUIDs for COM+ components are "well known" values that are used by both the COM servers implementing an interface(s) and by clients that are consuming the interface(s) from a COM server. So normally you wouldn't want to generate a new GUID when registering a COM server, but use the one the developer created when the COM server was developed. However if you don't know what the correct GUID to use is, then generating a new GUID will at least allow you to make progress in developing your script.
This may or may not fix the problem causing the 0x80110401, but it will definitely fix a problem you'll run into sooner or later.

Resources