Why aren't all EnvDTE assemblies Primary Interop…I'm COMfused?
I'm trying to understand how the Visual Studio EnvDTE Interop Assemblies work, and why they have been designed this way. New assemblies contain updated/new interfaces, and the recommendation by Microsoft is to use the most recent interface in VS2017. That looks like this:
EnvDTE.DTE dte = (EnvDTE.DTE)((IServiceProvider)Host).GetCOMService(typeof(DTE));
EnvDTE80.DTE2 dte2 = (EnvDTE80)dte;
EnvDTE.Solution solution = dte2.Solution; // Returns a Solution type, not Solution2
EnvDTE80.Solution2 solution2 = (EnvDTE80.Solution2)dte2.Solution;
In that snippet,the DTE2.Solution property returns type Solution and not Solution2 as I'd have expected... You must explicitly cast to access newer interfaces, which seems odd.
I searched the registry for each GUID of the EnvDTExxx assemblies, but the only CLSIDs I found with references to any of them were the Microsoft Visual Studio DTE Object and the Microsoft Visual Studio Solution Object. Both link to EnvDTE as their type library... And I can't find any COM object that uses the newer EnvDTExxx versions. Yet I see the newest interfaced in OleView!!! :
Does this mean newer EvDTExxx Assemblies rely on the origional EnvDTE to access the actual COM component? I believe the interfaces in OleView represent the actual interfaces on the COM component... but then why wouldn't the EnvDTE type library use the updated DTE2 interface?
To add to my confusion, I discovered only EnvDTE and EnvDTE80 are decorated with the PrimaryInteropAssemblyAttribute... while EnvDTE90-100 aren't! I'm assuming because the newer interop assemblies only expose types of EnvDTE (The PIA), there won't be type conflicts? But that doesn't explain why EnvDTE80 is marked as a PIA also...I thought there could only be one PIA!
Please rescue me from my COMfusion!
c# com com-interop t4 envdte
asked Nov 16 '18 at 2:35
FakeSaintFakeSaint
736
add a comment |
I'm trying to understand how the Visual Studio EnvDTE Interop Assemblies work, and why they have been designed this way. New assemblies contain updated/new interfaces, and the recommendation by Microsoft is to use the most recent interface in VS2017. That looks like this:
EnvDTE.DTE dte = (EnvDTE.DTE)((IServiceProvider)Host).GetCOMService(typeof(DTE));
EnvDTE80.DTE2 dte2 = (EnvDTE80)dte;
EnvDTE.Solution solution = dte2.Solution; // Returns a Solution type, not Solution2
EnvDTE80.Solution2 solution2 = (EnvDTE80.Solution2)dte2.Solution;
In that snippet,the DTE2.Solution property returns type Solution and not Solution2 as I'd have expected... You must explicitly cast to access newer interfaces, which seems odd.
I searched the registry for each GUID of the EnvDTExxx assemblies, but the only CLSIDs I found with references to any of them were the Microsoft Visual Studio DTE Object and the Microsoft Visual Studio Solution Object. Both link to EnvDTE as their type library... And I can't find any COM object that uses the newer EnvDTExxx versions. Yet I see the newest interfaced in OleView!!! :
Does this mean newer EvDTExxx Assemblies rely on the origional EnvDTE to access the actual COM component? I believe the interfaces in OleView represent the actual interfaces on the COM component... but then why wouldn't the EnvDTE type library use the updated DTE2 interface?
To add to my confusion, I discovered only EnvDTE and EnvDTE80 are decorated with the PrimaryInteropAssemblyAttribute... while EnvDTE90-100 aren't! I'm assuming because the newer interop assemblies only expose types of EnvDTE (The PIA), there won't be type conflicts? But that doesn't explain why EnvDTE80 is marked as a PIA also...I thought there could only be one PIA!
Please rescue me from my COMfusion!
c# com com-interop t4 envdte
asked Nov 16 '18 at 2:35
FakeSaintFakeSaint
736
1
possible still useful to read despite it's age: stackoverflow.com/questions/27448122/…
– JohnB
Nov 16 '18 at 2:51
Thanks, but I know how to get the updated interfaces. I just don't understand why they've been designed this way... It seems like they are releasing 2 PIA's for the same COM object, and then releasing non-Primary interop assemblies that reference the PIA's? The OleView of the COM object seems to show the type exposed by the newest PIA, but the old PIA is listed as the type library for the COM object
– FakeSaint
Nov 16 '18 at 3:02
add a comment |
I'm trying to understand how the Visual Studio EnvDTE Interop Assemblies work, and why they have been designed this way. New assemblies contain updated/new interfaces, and the recommendation by Microsoft is to use the most recent interface in VS2017. That looks like this:
EnvDTE.DTE dte = (EnvDTE.DTE)((IServiceProvider)Host).GetCOMService(typeof(DTE));
EnvDTE80.DTE2 dte2 = (EnvDTE80)dte;
EnvDTE.Solution solution = dte2.Solution; // Returns a Solution type, not Solution2
EnvDTE80.Solution2 solution2 = (EnvDTE80.Solution2)dte2.Solution;
In that snippet,the DTE2.Solution property returns type Solution and not Solution2 as I'd have expected... You must explicitly cast to access newer interfaces, which seems odd.
I searched the registry for each GUID of the EnvDTExxx assemblies, but the only CLSIDs I found with references to any of them were the Microsoft Visual Studio DTE Object and the Microsoft Visual Studio Solution Object. Both link to EnvDTE as their type library... And I can't find any COM object that uses the newer EnvDTExxx versions. Yet I see the newest interfaced in OleView!!! :
Does this mean newer EvDTExxx Assemblies rely on the origional EnvDTE to access the actual COM component? I believe the interfaces in OleView represent the actual interfaces on the COM component... but then why wouldn't the EnvDTE type library use the updated DTE2 interface?
To add to my confusion, I discovered only EnvDTE and EnvDTE80 are decorated with the PrimaryInteropAssemblyAttribute... while EnvDTE90-100 aren't! I'm assuming because the newer interop assemblies only expose types of EnvDTE (The PIA), there won't be type conflicts? But that doesn't explain why EnvDTE80 is marked as a PIA also...I thought there could only be one PIA!
Please rescue me from my COMfusion!
c# com com-interop t4 envdte
asked Nov 16 '18 at 2:35
FakeSaintFakeSaint
736
I'm trying to understand how the Visual Studio EnvDTE Interop Assemblies work, and why they have been designed this way. New assemblies contain updated/new interfaces, and the recommendation by Microsoft is to use the most recent interface in VS2017. That looks like this:
EnvDTE.DTE dte = (EnvDTE.DTE)((IServiceProvider)Host).GetCOMService(typeof(DTE));
EnvDTE80.DTE2 dte2 = (EnvDTE80)dte;
EnvDTE.Solution solution = dte2.Solution; // Returns a Solution type, not Solution2
EnvDTE80.Solution2 solution2 = (EnvDTE80.Solution2)dte2.Solution;
In that snippet,the DTE2.Solution property returns type Solution and not Solution2 as I'd have expected... You must explicitly cast to access newer interfaces, which seems odd.
I searched the registry for each GUID of the EnvDTExxx assemblies, but the only CLSIDs I found with references to any of them were the Microsoft Visual Studio DTE Object and the Microsoft Visual Studio Solution Object. Both link to EnvDTE as their type library... And I can't find any COM object that uses the newer EnvDTExxx versions. Yet I see the newest interfaced in OleView!!! :
Does this mean newer EvDTExxx Assemblies rely on the origional EnvDTE to access the actual COM component? I believe the interfaces in OleView represent the actual interfaces on the COM component... but then why wouldn't the EnvDTE type library use the updated DTE2 interface?
To add to my confusion, I discovered only EnvDTE and EnvDTE80 are decorated with the PrimaryInteropAssemblyAttribute... while EnvDTE90-100 aren't! I'm assuming because the newer interop assemblies only expose types of EnvDTE (The PIA), there won't be type conflicts? But that doesn't explain why EnvDTE80 is marked as a PIA also...I thought there could only be one PIA!
Please rescue me from my COMfusion!
c# com com-interop t4 envdte
c# com com-interop t4 envdte
asked Nov 16 '18 at 2:35
FakeSaintFakeSaint
736
asked Nov 16 '18 at 2:35
FakeSaintFakeSaint
736
edited Nov 16 '18 at 3:23
FakeSaint
asked Nov 16 '18 at 2:35
FakeSaintFakeSaint
736
asked Nov 16 '18 at 2:35
FakeSaintFakeSaint
736
asked Nov 16 '18 at 2:35
FakeSaintFakeSaint
736
736
1
possible still useful to read despite it's age: stackoverflow.com/questions/27448122/…
– JohnB
Nov 16 '18 at 2:51
Thanks, but I know how to get the updated interfaces. I just don't understand why they've been designed this way... It seems like they are releasing 2 PIA's for the same COM object, and then releasing non-Primary interop assemblies that reference the PIA's? The OleView of the COM object seems to show the type exposed by the newest PIA, but the old PIA is listed as the type library for the COM object
– FakeSaint
Nov 16 '18 at 3:02
add a comment |
1
possible still useful to read despite it's age: stackoverflow.com/questions/27448122/…
– JohnB
Nov 16 '18 at 2:51
Thanks, but I know how to get the updated interfaces. I just don't understand why they've been designed this way... It seems like they are releasing 2 PIA's for the same COM object, and then releasing non-Primary interop assemblies that reference the PIA's? The OleView of the COM object seems to show the type exposed by the newest PIA, but the old PIA is listed as the type library for the COM object
– FakeSaint
Nov 16 '18 at 3:02
1
1
possible still useful to read despite it's age: stackoverflow.com/questions/27448122/…
– JohnB
Nov 16 '18 at 2:51
possible still useful to read despite it's age: stackoverflow.com/questions/27448122/…
– JohnB
Nov 16 '18 at 2:51
Thanks, but I know how to get the updated interfaces. I just don't understand why they've been designed this way... It seems like they are releasing 2 PIA's for the same COM object, and then releasing non-Primary interop assemblies that reference the PIA's? The OleView of the COM object seems to show the type exposed by the newest PIA, but the old PIA is listed as the type library for the COM object
– FakeSaint
Nov 16 '18 at 3:02
Thanks, but I know how to get the updated interfaces. I just don't understand why they've been designed this way... It seems like they are releasing 2 PIA's for the same COM object, and then releasing non-Primary interop assemblies that reference the PIA's? The OleView of the COM object seems to show the type exposed by the newest PIA, but the old PIA is listed as the type library for the COM object
– FakeSaint
Nov 16 '18 at 3:02
add a comment |
1 Answer
1
active
oldest
votes
Com types really are just interfaces, and it follows the same rules as .NET interfaces.
In a interface you can't change the return type of a defined method in a derived method without breaking binary compatibility.
So because the interfaces are essentially
public interface EnvDTE
{
Solution Solution {get;}
//other stuff
}
public EnvDTE80 : EnvDTE
{
//more other stuff
}
the return must be the same to keep binary compatibility.
answered Nov 16 '18 at 3:23
Scott ChamberlainScott Chamberlain
99.2k25185328
Thanks! Sorry I don't think I've done my question justice. My confusion is why additional interop assemblies are being added in the first place (with one as a PIA and the rest not), and why they aren't returning the most recent types. I understand what you are saying though, but they could'nt they have just included new methods with the correct return type?
– FakeSaint
Nov 16 '18 at 3:30
They can't return the most recent types. You are working with interfaces, and the interface contract states it returns the original old type. As for why they are not marked PIA I have no idea.
– Scott Chamberlain
Nov 16 '18 at 3:33
Yea I know they can't as written, but I'm wondering why the designers wrote them that way. I feel they could have written the interface such that it returned the newest version... unless there is something I misunderstand about Interop Assemblies
– FakeSaint
Nov 16 '18 at 3:41
IE right now, the new interfaces inherit from the old ones and then hide the old members. The new interface method declaration still returns the out-dated type... probably for a good reason I just don't understand :S
– FakeSaint
Nov 16 '18 at 3:45
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53330639%2fwhy-arent-all-envdte-assemblies-primary-interop-im-comfused%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
1 Answer
1
active
oldest
votes
1 Answer
1
active
oldest
votes
active
oldest
votes
active
oldest
votes
Com types really are just interfaces, and it follows the same rules as .NET interfaces.
In a interface you can't change the return type of a defined method in a derived method without breaking binary compatibility.
So because the interfaces are essentially
public interface EnvDTE
{
Solution Solution {get;}
//other stuff
}
public EnvDTE80 : EnvDTE
{
//more other stuff
}
the return must be the same to keep binary compatibility.
answered Nov 16 '18 at 3:23
Scott ChamberlainScott Chamberlain
99.2k25185328
Thanks! Sorry I don't think I've done my question justice. My confusion is why additional interop assemblies are being added in the first place (with one as a PIA and the rest not), and why they aren't returning the most recent types. I understand what you are saying though, but they could'nt they have just included new methods with the correct return type?
– FakeSaint
Nov 16 '18 at 3:30
They can't return the most recent types. You are working with interfaces, and the interface contract states it returns the original old type. As for why they are not marked PIA I have no idea.
– Scott Chamberlain
Nov 16 '18 at 3:33
Yea I know they can't as written, but I'm wondering why the designers wrote them that way. I feel they could have written the interface such that it returned the newest version... unless there is something I misunderstand about Interop Assemblies
– FakeSaint
Nov 16 '18 at 3:41
IE right now, the new interfaces inherit from the old ones and then hide the old members. The new interface method declaration still returns the out-dated type... probably for a good reason I just don't understand :S
– FakeSaint
Nov 16 '18 at 3:45
add a comment |
Com types really are just interfaces, and it follows the same rules as .NET interfaces.
In a interface you can't change the return type of a defined method in a derived method without breaking binary compatibility.
So because the interfaces are essentially
public interface EnvDTE
{
Solution Solution {get;}
//other stuff
}
public EnvDTE80 : EnvDTE
{
//more other stuff
}
the return must be the same to keep binary compatibility.
answered Nov 16 '18 at 3:23
Scott ChamberlainScott Chamberlain
99.2k25185328
Thanks! Sorry I don't think I've done my question justice. My confusion is why additional interop assemblies are being added in the first place (with one as a PIA and the rest not), and why they aren't returning the most recent types. I understand what you are saying though, but they could'nt they have just included new methods with the correct return type?
– FakeSaint
Nov 16 '18 at 3:30
They can't return the most recent types. You are working with interfaces, and the interface contract states it returns the original old type. As for why they are not marked PIA I have no idea.
– Scott Chamberlain
Nov 16 '18 at 3:33
Yea I know they can't as written, but I'm wondering why the designers wrote them that way. I feel they could have written the interface such that it returned the newest version... unless there is something I misunderstand about Interop Assemblies
– FakeSaint
Nov 16 '18 at 3:41
IE right now, the new interfaces inherit from the old ones and then hide the old members. The new interface method declaration still returns the out-dated type... probably for a good reason I just don't understand :S
– FakeSaint
Nov 16 '18 at 3:45
add a comment |
Com types really are just interfaces, and it follows the same rules as .NET interfaces.
In a interface you can't change the return type of a defined method in a derived method without breaking binary compatibility.
So because the interfaces are essentially
public interface EnvDTE
{
Solution Solution {get;}
//other stuff
}
public EnvDTE80 : EnvDTE
{
//more other stuff
}
the return must be the same to keep binary compatibility.
answered Nov 16 '18 at 3:23
Scott ChamberlainScott Chamberlain
99.2k25185328
Com types really are just interfaces, and it follows the same rules as .NET interfaces.
In a interface you can't change the return type of a defined method in a derived method without breaking binary compatibility.
So because the interfaces are essentially
public interface EnvDTE
{
Solution Solution {get;}
//other stuff
}
public EnvDTE80 : EnvDTE
{
//more other stuff
}
the return must be the same to keep binary compatibility.
answered Nov 16 '18 at 3:23
Scott ChamberlainScott Chamberlain
99.2k25185328
answered Nov 16 '18 at 3:23
Scott ChamberlainScott Chamberlain
99.2k25185328
answered Nov 16 '18 at 3:23
Scott ChamberlainScott Chamberlain
99.2k25185328
answered Nov 16 '18 at 3:23
Scott ChamberlainScott Chamberlain
99.2k25185328
99.2k25185328
Thanks! Sorry I don't think I've done my question justice. My confusion is why additional interop assemblies are being added in the first place (with one as a PIA and the rest not), and why they aren't returning the most recent types. I understand what you are saying though, but they could'nt they have just included new methods with the correct return type?
– FakeSaint
Nov 16 '18 at 3:30
They can't return the most recent types. You are working with interfaces, and the interface contract states it returns the original old type. As for why they are not marked PIA I have no idea.
– Scott Chamberlain
Nov 16 '18 at 3:33
Yea I know they can't as written, but I'm wondering why the designers wrote them that way. I feel they could have written the interface such that it returned the newest version... unless there is something I misunderstand about Interop Assemblies
– FakeSaint
Nov 16 '18 at 3:41
IE right now, the new interfaces inherit from the old ones and then hide the old members. The new interface method declaration still returns the out-dated type... probably for a good reason I just don't understand :S
– FakeSaint
Nov 16 '18 at 3:45
add a comment |
Thanks! Sorry I don't think I've done my question justice. My confusion is why additional interop assemblies are being added in the first place (with one as a PIA and the rest not), and why they aren't returning the most recent types. I understand what you are saying though, but they could'nt they have just included new methods with the correct return type?
– FakeSaint
Nov 16 '18 at 3:30
They can't return the most recent types. You are working with interfaces, and the interface contract states it returns the original old type. As for why they are not marked PIA I have no idea.
– Scott Chamberlain
Nov 16 '18 at 3:33
Yea I know they can't as written, but I'm wondering why the designers wrote them that way. I feel they could have written the interface such that it returned the newest version... unless there is something I misunderstand about Interop Assemblies
– FakeSaint
Nov 16 '18 at 3:41
IE right now, the new interfaces inherit from the old ones and then hide the old members. The new interface method declaration still returns the out-dated type... probably for a good reason I just don't understand :S
– FakeSaint
Nov 16 '18 at 3:45
Thanks! Sorry I don't think I've done my question justice. My confusion is why additional interop assemblies are being added in the first place (with one as a PIA and the rest not), and why they aren't returning the most recent types. I understand what you are saying though, but they could'nt they have just included new methods with the correct return type?
– FakeSaint
Nov 16 '18 at 3:30
Thanks! Sorry I don't think I've done my question justice. My confusion is why additional interop assemblies are being added in the first place (with one as a PIA and the rest not), and why they aren't returning the most recent types. I understand what you are saying though, but they could'nt they have just included new methods with the correct return type?
– FakeSaint
Nov 16 '18 at 3:30
They can't return the most recent types. You are working with interfaces, and the interface contract states it returns the original old type. As for why they are not marked PIA I have no idea.
– Scott Chamberlain
Nov 16 '18 at 3:33
They can't return the most recent types. You are working with interfaces, and the interface contract states it returns the original old type. As for why they are not marked PIA I have no idea.
– Scott Chamberlain
Nov 16 '18 at 3:33
Yea I know they can't as written, but I'm wondering why the designers wrote them that way. I feel they could have written the interface such that it returned the newest version... unless there is something I misunderstand about Interop Assemblies
– FakeSaint
Nov 16 '18 at 3:41
Yea I know they can't as written, but I'm wondering why the designers wrote them that way. I feel they could have written the interface such that it returned the newest version... unless there is something I misunderstand about Interop Assemblies
– FakeSaint
Nov 16 '18 at 3:41
IE right now, the new interfaces inherit from the old ones and then hide the old members. The new interface method declaration still returns the out-dated type... probably for a good reason I just don't understand :S
– FakeSaint
Nov 16 '18 at 3:45
IE right now, the new interfaces inherit from the old ones and then hide the old members. The new interface method declaration still returns the out-dated type... probably for a good reason I just don't understand :S
– FakeSaint
Nov 16 '18 at 3:45
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53330639%2fwhy-arent-all-envdte-assemblies-primary-interop-im-comfused%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
1
possible still useful to read despite it's age: stackoverflow.com/questions/27448122/…
– JohnB
Nov 16 '18 at 2:51
Thanks, but I know how to get the updated interfaces. I just don't understand why they've been designed this way... It seems like they are releasing 2 PIA's for the same COM object, and then releasing non-Primary interop assemblies that reference the PIA's? The OleView of the COM object seems to show the type exposed by the newest PIA, but the old PIA is listed as the type library for the COM object
– FakeSaint
Nov 16 '18 at 3:02