Visual Studio Setup Project (vdproj) - STDOLE, how to properly register COM DLL?Typelib Generation and Installation with WiXVisual Studio Setup project - force installation of a .DLL?Visual Studio Installer - Registry keys being overwritten by COMHow to convert 100+ Visual Studio Installer Project (vdproj) to Wix Installers?Visual Studio Setup project not registering DLL on upgradeTools to create installers or setup programs in Visual Studio 2015Visual Studio 2015 vdproj — Change or Remove Digital SignatureSelf extracting setup with Visual Studio 2015 Installer projectSetup projects in Visual Studio 2015Why is this DLL ignored in a VS 2015 Installer Projects Extension setup project?
Does the Wild Magic sorcerer's Tides of Chaos feature grant advantage on all attacks, or just the first one?
What happens if a short can't be covered?
What purpose does mercury dichloride have in fireworks?
When do flights get cancelled due to fog?
What exactly is a "murder hobo"?
Diagram with cylinder shapes and rectangles
Examples of fluid (including air) being used to transmit digital data?
Is it possible for a character at any level to cast all 44 Cantrips in one week without Magic Items?
Four ships at the ocean with the same distance
Why did the frequency of the word "черт" (devil) in books increase by a few times since the October Revolution?
Jimmy needs your help!
What is the highest level of accuracy in motion control a Victorian society could achieve?
How can I reset Safari when Safari is broken?
Array or vector? Two dimensional array or matrix?
Will Jimmy fall off his platform?
How should I ask for a "pint" in countries that use metric?
Replacing loop with functional style
How do ballistic trajectories work in a ring world?
Calculate the largest palindromic number from the product of two 6-digit numbers (100000 to 999999)
Define functions in a tikzcd diagram
Sense of humor in your sci-fi stories
Computer name naming convention for security
Need a non-volatile memory IC with near unlimited read/write operations capability
Taking my Ph.D. advisor out for dinner after graduation
Visual Studio Setup Project (vdproj) - STDOLE, how to properly register COM DLL?
Typelib Generation and Installation with WiXVisual Studio Setup project - force installation of a .DLL?Visual Studio Installer - Registry keys being overwritten by COMHow to convert 100+ Visual Studio Installer Project (vdproj) to Wix Installers?Visual Studio Setup project not registering DLL on upgradeTools to create installers or setup programs in Visual Studio 2015Visual Studio 2015 vdproj — Change or Remove Digital SignatureSelf extracting setup with Visual Studio 2015 Installer projectSetup projects in Visual Studio 2015Why is this DLL ignored in a VS 2015 Installer Projects Extension setup project?
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty,.everyoneloves__bot-mid-leaderboard:empty margin-bottom:0;
I am using Visual Studio 2015 Setup Project.
I have a COM DLL in setup that has a reference to the STDOLE (system type library, 00020430-0000-0000-C000-000000000046, that must not be registered, as of my understanding, because it is a protected file/registration). If you try to register it, you'll hit an error (warning) when installing the MSI.
Nevertheless, the vdproj extension adds the the registration for this DLL to the "TypeLib" MSI table. It appears that it does not do it always though, but under some conditions I cannot deduce. I have no option to exclude that tlb, it is somehow keeps reappearing (from dependencies probably?)
- Why does vdproj tries to register that DLL that should not be registered?
- How to avoid this? I tried adding manual post-edit of the produced MSI with a script to remove that tlb, and that worked; however it seems to be a completely wicked approach to the problem.
For this particular project, I am stuck with the Visual Studio Installer, and cannot switch to more reasonable and transparent alternatives (such as WiX). Any help or advice is highly appreciated!
visual-studio-2015 windows-installer vdproj
asked Mar 25 at 21:24
NikolayNikolay
6,0842 gold badges15 silver badges34 bronze badges
add a comment |
I am using Visual Studio 2015 Setup Project.
I have a COM DLL in setup that has a reference to the STDOLE (system type library, 00020430-0000-0000-C000-000000000046, that must not be registered, as of my understanding, because it is a protected file/registration). If you try to register it, you'll hit an error (warning) when installing the MSI.
Nevertheless, the vdproj extension adds the the registration for this DLL to the "TypeLib" MSI table. It appears that it does not do it always though, but under some conditions I cannot deduce. I have no option to exclude that tlb, it is somehow keeps reappearing (from dependencies probably?)
- Why does vdproj tries to register that DLL that should not be registered?
- How to avoid this? I tried adding manual post-edit of the produced MSI with a script to remove that tlb, and that worked; however it seems to be a completely wicked approach to the problem.
For this particular project, I am stuck with the Visual Studio Installer, and cannot switch to more reasonable and transparent alternatives (such as WiX). Any help or advice is highly appreciated!
visual-studio-2015 windows-installer vdproj
asked Mar 25 at 21:24
NikolayNikolay
6,0842 gold badges15 silver badges34 bronze badges
Is this a VB6 COM dll? Is it a public DLL that you can put somewhere to look at? Maybe it is even a standard dll? Perhaps it is not even necessary to add?
– Stein Åsmul
Mar 26 at 1:02
It is a .NET assembly (that uses some things defined in the STDOLE). It's closed source, so I can't change this dependency :[
– Nikolay
Mar 26 at 13:05
So it must be a .NET assembly that is registered for COM interop then? It has been a while since I worked on that. Are there COM components in there as well (dlls, ocx, etc...)?
– Stein Åsmul
Mar 26 at 14:18
Correct, this is a .NET assembly to be registered for COM interop. Please note that this one is not "Primary Project Output" causing the issue, but a dependent assembly (that is auto-populated by the vdproj extension, under the "dependencies" list).
– Nikolay
Mar 26 at 14:39
Updated my answer last night. The registry table approach will cause some validation issues, but it should work OK. I do believe registering the component prior to building should eliminate the registry key as well. Haven't tested.
– Stein Åsmul
Mar 27 at 12:23
add a comment |
I am using Visual Studio 2015 Setup Project.
I have a COM DLL in setup that has a reference to the STDOLE (system type library, 00020430-0000-0000-C000-000000000046, that must not be registered, as of my understanding, because it is a protected file/registration). If you try to register it, you'll hit an error (warning) when installing the MSI.
Nevertheless, the vdproj extension adds the the registration for this DLL to the "TypeLib" MSI table. It appears that it does not do it always though, but under some conditions I cannot deduce. I have no option to exclude that tlb, it is somehow keeps reappearing (from dependencies probably?)
- Why does vdproj tries to register that DLL that should not be registered?
- How to avoid this? I tried adding manual post-edit of the produced MSI with a script to remove that tlb, and that worked; however it seems to be a completely wicked approach to the problem.
For this particular project, I am stuck with the Visual Studio Installer, and cannot switch to more reasonable and transparent alternatives (such as WiX). Any help or advice is highly appreciated!
visual-studio-2015 windows-installer vdproj
asked Mar 25 at 21:24
NikolayNikolay
6,0842 gold badges15 silver badges34 bronze badges
I am using Visual Studio 2015 Setup Project.
I have a COM DLL in setup that has a reference to the STDOLE (system type library, 00020430-0000-0000-C000-000000000046, that must not be registered, as of my understanding, because it is a protected file/registration). If you try to register it, you'll hit an error (warning) when installing the MSI.
Nevertheless, the vdproj extension adds the the registration for this DLL to the "TypeLib" MSI table. It appears that it does not do it always though, but under some conditions I cannot deduce. I have no option to exclude that tlb, it is somehow keeps reappearing (from dependencies probably?)
- Why does vdproj tries to register that DLL that should not be registered?
- How to avoid this? I tried adding manual post-edit of the produced MSI with a script to remove that tlb, and that worked; however it seems to be a completely wicked approach to the problem.
For this particular project, I am stuck with the Visual Studio Installer, and cannot switch to more reasonable and transparent alternatives (such as WiX). Any help or advice is highly appreciated!
visual-studio-2015 windows-installer vdproj
visual-studio-2015 windows-installer vdproj
asked Mar 25 at 21:24
NikolayNikolay
6,0842 gold badges15 silver badges34 bronze badges
asked Mar 25 at 21:24
NikolayNikolay
6,0842 gold badges15 silver badges34 bronze badges
edited Mar 25 at 21:39
Nikolay
asked Mar 25 at 21:24
NikolayNikolay
6,0842 gold badges15 silver badges34 bronze badges
asked Mar 25 at 21:24
NikolayNikolay
6,0842 gold badges15 silver badges34 bronze badges
asked Mar 25 at 21:24
NikolayNikolay
6,0842 gold badges15 silver badges34 bronze badges
6,0842 gold badges15 silver badges34 bronze badges
Is this a VB6 COM dll? Is it a public DLL that you can put somewhere to look at? Maybe it is even a standard dll? Perhaps it is not even necessary to add?
– Stein Åsmul
Mar 26 at 1:02
It is a .NET assembly (that uses some things defined in the STDOLE). It's closed source, so I can't change this dependency :[
– Nikolay
Mar 26 at 13:05
So it must be a .NET assembly that is registered for COM interop then? It has been a while since I worked on that. Are there COM components in there as well (dlls, ocx, etc...)?
– Stein Åsmul
Mar 26 at 14:18
Correct, this is a .NET assembly to be registered for COM interop. Please note that this one is not "Primary Project Output" causing the issue, but a dependent assembly (that is auto-populated by the vdproj extension, under the "dependencies" list).
– Nikolay
Mar 26 at 14:39
Updated my answer last night. The registry table approach will cause some validation issues, but it should work OK. I do believe registering the component prior to building should eliminate the registry key as well. Haven't tested.
– Stein Åsmul
Mar 27 at 12:23
add a comment |
Is this a VB6 COM dll? Is it a public DLL that you can put somewhere to look at? Maybe it is even a standard dll? Perhaps it is not even necessary to add?
– Stein Åsmul
Mar 26 at 1:02
It is a .NET assembly (that uses some things defined in the STDOLE). It's closed source, so I can't change this dependency :[
– Nikolay
Mar 26 at 13:05
So it must be a .NET assembly that is registered for COM interop then? It has been a while since I worked on that. Are there COM components in there as well (dlls, ocx, etc...)?
– Stein Åsmul
Mar 26 at 14:18
Correct, this is a .NET assembly to be registered for COM interop. Please note that this one is not "Primary Project Output" causing the issue, but a dependent assembly (that is auto-populated by the vdproj extension, under the "dependencies" list).
– Nikolay
Mar 26 at 14:39
Updated my answer last night. The registry table approach will cause some validation issues, but it should work OK. I do believe registering the component prior to building should eliminate the registry key as well. Haven't tested.
– Stein Åsmul
Mar 27 at 12:23
Is this a VB6 COM dll? Is it a public DLL that you can put somewhere to look at? Maybe it is even a standard dll? Perhaps it is not even necessary to add?
– Stein Åsmul
Mar 26 at 1:02
Is this a VB6 COM dll? Is it a public DLL that you can put somewhere to look at? Maybe it is even a standard dll? Perhaps it is not even necessary to add?
– Stein Åsmul
Mar 26 at 1:02
It is a .NET assembly (that uses some things defined in the STDOLE). It's closed source, so I can't change this dependency :[
– Nikolay
Mar 26 at 13:05
It is a .NET assembly (that uses some things defined in the STDOLE). It's closed source, so I can't change this dependency :[
– Nikolay
Mar 26 at 13:05
So it must be a .NET assembly that is registered for COM interop then? It has been a while since I worked on that. Are there COM components in there as well (dlls, ocx, etc...)?
– Stein Åsmul
Mar 26 at 14:18
So it must be a .NET assembly that is registered for COM interop then? It has been a while since I worked on that. Are there COM components in there as well (dlls, ocx, etc...)?
– Stein Åsmul
Mar 26 at 14:18
Correct, this is a .NET assembly to be registered for COM interop. Please note that this one is not "Primary Project Output" causing the issue, but a dependent assembly (that is auto-populated by the vdproj extension, under the "dependencies" list).
– Nikolay
Mar 26 at 14:39
Correct, this is a .NET assembly to be registered for COM interop. Please note that this one is not "Primary Project Output" causing the issue, but a dependent assembly (that is auto-populated by the vdproj extension, under the "dependencies" list).
– Nikolay
Mar 26 at 14:39
Updated my answer last night. The registry table approach will cause some validation issues, but it should work OK. I do believe registering the component prior to building should eliminate the registry key as well. Haven't tested.
– Stein Åsmul
Mar 27 at 12:23
Updated my answer last night. The registry table approach will cause some validation issues, but it should work OK. I do believe registering the component prior to building should eliminate the registry key as well. Haven't tested.
– Stein Åsmul
Mar 27 at 12:23
add a comment |
1 Answer
1
active
oldest
votes
VB6 Runtime: The registry key: Typelib000204EF-0000-0000-C000-000000000046 is part of the Visual Basic 6 Runtime and it is a known issue in WiX that heat.exe extraction of COM data erronously brings along this registry key for each ActiveX or COM component. Note that this is not WiX's fault, but a general issue with VB6. Hence the problem you see in Visual Studio installer projects as well.
From the WiX help manual (for heat.exe) (multi-purpose tool, one of which is COM registration extraction): "...When registering a COM
component created in VB6 it adds registry entries that are part of the
VB6 runtime component. This flag is recommend for VB6 components to
avoid breaking the VB6 runtime on uninstall. The following values are
excluded:CLSIDD5DE8D20-5BB8-11D1-A1E3-00A0C90F2731,
TypelibEA544A21-C82D-11D1-A3E4-00A0C90AEA82,Typelib000204EF-0000-0000-C000-000000000046, any interfaces that reference these two type libraries`"
Resolution: And now the hard part, what is the actual fix? Frankly I don't have the time to test right now, but I suppose you can just open the final MSI with Orca and remove these entries - should they be there. I guess that is exactly what you are doing now, so you are back to square one, but at least there is a bit of clarity as to what causes the problem. I suppose you can try to run the build when the VB6 component is unregistered as opposed to when it is registered? That would make some sort of sense that it is only extracting the keys if the component is unregistered when you build? If this is the case, maybe try to self-register your VB6 component prior to the setup build.
RegSpy.exe: You can use a tool called RegSpy (or RegSpy2 actually) to extract the COM registration from a COM file. You can find the exe in the "Release" folder, then you go:
regspy.exe richtx32.ocx >> richtx32.reg
Then you can import the reg file to your Visual Studio Installer project. Remember to replace the hard coded paths with MSI directory properties and remove the erroneous VB6 entries mentioned above.
VSProj: In Visual Studio, Right click Visual Studio Installer Project => View => Registry => Right Click Top Node => Import...
answered Mar 26 at 4:27
Stein ÅsmulStein Åsmul
24.3k15 gold badges61 silver badges123 bronze badges
Thank you for the info.. the thing is it is not WIX, but Visual Studio Setup Project (vdproj). With WIX one could simply do it all "by hand" and avoid auto-com-extraction. Also, it's not really a VB6 component, but a .NET assembly that has a reference to STDOLE.. For now yes, just removing these entries with "fix" script..
– Nikolay
Mar 26 at 13:00
I guess you could just register the COM stuff via the registry table instead of the COM-tables if you have to. Provided the registration remains stable and isn't generated on every build of the dll you could then make do with the same registry data for every release. Let me have a look in Visual Studio.
– Stein Åsmul
Mar 26 at 14:28
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%2f55346620%2fvisual-studio-setup-project-vdproj-stdole-how-to-properly-register-com-dll%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
VB6 Runtime: The registry key: Typelib000204EF-0000-0000-C000-000000000046 is part of the Visual Basic 6 Runtime and it is a known issue in WiX that heat.exe extraction of COM data erronously brings along this registry key for each ActiveX or COM component. Note that this is not WiX's fault, but a general issue with VB6. Hence the problem you see in Visual Studio installer projects as well.
From the WiX help manual (for heat.exe) (multi-purpose tool, one of which is COM registration extraction): "...When registering a COM
component created in VB6 it adds registry entries that are part of the
VB6 runtime component. This flag is recommend for VB6 components to
avoid breaking the VB6 runtime on uninstall. The following values are
excluded:CLSIDD5DE8D20-5BB8-11D1-A1E3-00A0C90F2731,
TypelibEA544A21-C82D-11D1-A3E4-00A0C90AEA82,Typelib000204EF-0000-0000-C000-000000000046, any interfaces that reference these two type libraries`"
Resolution: And now the hard part, what is the actual fix? Frankly I don't have the time to test right now, but I suppose you can just open the final MSI with Orca and remove these entries - should they be there. I guess that is exactly what you are doing now, so you are back to square one, but at least there is a bit of clarity as to what causes the problem. I suppose you can try to run the build when the VB6 component is unregistered as opposed to when it is registered? That would make some sort of sense that it is only extracting the keys if the component is unregistered when you build? If this is the case, maybe try to self-register your VB6 component prior to the setup build.
RegSpy.exe: You can use a tool called RegSpy (or RegSpy2 actually) to extract the COM registration from a COM file. You can find the exe in the "Release" folder, then you go:
regspy.exe richtx32.ocx >> richtx32.reg
Then you can import the reg file to your Visual Studio Installer project. Remember to replace the hard coded paths with MSI directory properties and remove the erroneous VB6 entries mentioned above.
VSProj: In Visual Studio, Right click Visual Studio Installer Project => View => Registry => Right Click Top Node => Import...
answered Mar 26 at 4:27
Stein ÅsmulStein Åsmul
24.3k15 gold badges61 silver badges123 bronze badges
Thank you for the info.. the thing is it is not WIX, but Visual Studio Setup Project (vdproj). With WIX one could simply do it all "by hand" and avoid auto-com-extraction. Also, it's not really a VB6 component, but a .NET assembly that has a reference to STDOLE.. For now yes, just removing these entries with "fix" script..
– Nikolay
Mar 26 at 13:00
I guess you could just register the COM stuff via the registry table instead of the COM-tables if you have to. Provided the registration remains stable and isn't generated on every build of the dll you could then make do with the same registry data for every release. Let me have a look in Visual Studio.
– Stein Åsmul
Mar 26 at 14:28
add a comment |
VB6 Runtime: The registry key: Typelib000204EF-0000-0000-C000-000000000046 is part of the Visual Basic 6 Runtime and it is a known issue in WiX that heat.exe extraction of COM data erronously brings along this registry key for each ActiveX or COM component. Note that this is not WiX's fault, but a general issue with VB6. Hence the problem you see in Visual Studio installer projects as well.
From the WiX help manual (for heat.exe) (multi-purpose tool, one of which is COM registration extraction): "...When registering a COM
component created in VB6 it adds registry entries that are part of the
VB6 runtime component. This flag is recommend for VB6 components to
avoid breaking the VB6 runtime on uninstall. The following values are
excluded:CLSIDD5DE8D20-5BB8-11D1-A1E3-00A0C90F2731,
TypelibEA544A21-C82D-11D1-A3E4-00A0C90AEA82,Typelib000204EF-0000-0000-C000-000000000046, any interfaces that reference these two type libraries`"
Resolution: And now the hard part, what is the actual fix? Frankly I don't have the time to test right now, but I suppose you can just open the final MSI with Orca and remove these entries - should they be there. I guess that is exactly what you are doing now, so you are back to square one, but at least there is a bit of clarity as to what causes the problem. I suppose you can try to run the build when the VB6 component is unregistered as opposed to when it is registered? That would make some sort of sense that it is only extracting the keys if the component is unregistered when you build? If this is the case, maybe try to self-register your VB6 component prior to the setup build.
RegSpy.exe: You can use a tool called RegSpy (or RegSpy2 actually) to extract the COM registration from a COM file. You can find the exe in the "Release" folder, then you go:
regspy.exe richtx32.ocx >> richtx32.reg
Then you can import the reg file to your Visual Studio Installer project. Remember to replace the hard coded paths with MSI directory properties and remove the erroneous VB6 entries mentioned above.
VSProj: In Visual Studio, Right click Visual Studio Installer Project => View => Registry => Right Click Top Node => Import...
answered Mar 26 at 4:27
Stein ÅsmulStein Åsmul
24.3k15 gold badges61 silver badges123 bronze badges
Thank you for the info.. the thing is it is not WIX, but Visual Studio Setup Project (vdproj). With WIX one could simply do it all "by hand" and avoid auto-com-extraction. Also, it's not really a VB6 component, but a .NET assembly that has a reference to STDOLE.. For now yes, just removing these entries with "fix" script..
– Nikolay
Mar 26 at 13:00
I guess you could just register the COM stuff via the registry table instead of the COM-tables if you have to. Provided the registration remains stable and isn't generated on every build of the dll you could then make do with the same registry data for every release. Let me have a look in Visual Studio.
– Stein Åsmul
Mar 26 at 14:28
add a comment |
VB6 Runtime: The registry key: Typelib000204EF-0000-0000-C000-000000000046 is part of the Visual Basic 6 Runtime and it is a known issue in WiX that heat.exe extraction of COM data erronously brings along this registry key for each ActiveX or COM component. Note that this is not WiX's fault, but a general issue with VB6. Hence the problem you see in Visual Studio installer projects as well.
From the WiX help manual (for heat.exe) (multi-purpose tool, one of which is COM registration extraction): "...When registering a COM
component created in VB6 it adds registry entries that are part of the
VB6 runtime component. This flag is recommend for VB6 components to
avoid breaking the VB6 runtime on uninstall. The following values are
excluded:CLSIDD5DE8D20-5BB8-11D1-A1E3-00A0C90F2731,
TypelibEA544A21-C82D-11D1-A3E4-00A0C90AEA82,Typelib000204EF-0000-0000-C000-000000000046, any interfaces that reference these two type libraries`"
Resolution: And now the hard part, what is the actual fix? Frankly I don't have the time to test right now, but I suppose you can just open the final MSI with Orca and remove these entries - should they be there. I guess that is exactly what you are doing now, so you are back to square one, but at least there is a bit of clarity as to what causes the problem. I suppose you can try to run the build when the VB6 component is unregistered as opposed to when it is registered? That would make some sort of sense that it is only extracting the keys if the component is unregistered when you build? If this is the case, maybe try to self-register your VB6 component prior to the setup build.
RegSpy.exe: You can use a tool called RegSpy (or RegSpy2 actually) to extract the COM registration from a COM file. You can find the exe in the "Release" folder, then you go:
regspy.exe richtx32.ocx >> richtx32.reg
Then you can import the reg file to your Visual Studio Installer project. Remember to replace the hard coded paths with MSI directory properties and remove the erroneous VB6 entries mentioned above.
VSProj: In Visual Studio, Right click Visual Studio Installer Project => View => Registry => Right Click Top Node => Import...
answered Mar 26 at 4:27
Stein ÅsmulStein Åsmul
24.3k15 gold badges61 silver badges123 bronze badges
VB6 Runtime: The registry key: Typelib000204EF-0000-0000-C000-000000000046 is part of the Visual Basic 6 Runtime and it is a known issue in WiX that heat.exe extraction of COM data erronously brings along this registry key for each ActiveX or COM component. Note that this is not WiX's fault, but a general issue with VB6. Hence the problem you see in Visual Studio installer projects as well.
From the WiX help manual (for heat.exe) (multi-purpose tool, one of which is COM registration extraction): "...When registering a COM
component created in VB6 it adds registry entries that are part of the
VB6 runtime component. This flag is recommend for VB6 components to
avoid breaking the VB6 runtime on uninstall. The following values are
excluded:CLSIDD5DE8D20-5BB8-11D1-A1E3-00A0C90F2731,
TypelibEA544A21-C82D-11D1-A3E4-00A0C90AEA82,Typelib000204EF-0000-0000-C000-000000000046, any interfaces that reference these two type libraries`"
Resolution: And now the hard part, what is the actual fix? Frankly I don't have the time to test right now, but I suppose you can just open the final MSI with Orca and remove these entries - should they be there. I guess that is exactly what you are doing now, so you are back to square one, but at least there is a bit of clarity as to what causes the problem. I suppose you can try to run the build when the VB6 component is unregistered as opposed to when it is registered? That would make some sort of sense that it is only extracting the keys if the component is unregistered when you build? If this is the case, maybe try to self-register your VB6 component prior to the setup build.
RegSpy.exe: You can use a tool called RegSpy (or RegSpy2 actually) to extract the COM registration from a COM file. You can find the exe in the "Release" folder, then you go:
regspy.exe richtx32.ocx >> richtx32.reg
Then you can import the reg file to your Visual Studio Installer project. Remember to replace the hard coded paths with MSI directory properties and remove the erroneous VB6 entries mentioned above.
VSProj: In Visual Studio, Right click Visual Studio Installer Project => View => Registry => Right Click Top Node => Import...
answered Mar 26 at 4:27
Stein ÅsmulStein Åsmul
24.3k15 gold badges61 silver badges123 bronze badges
edited Mar 26 at 16:53
answered Mar 26 at 4:27
Stein ÅsmulStein Åsmul
24.3k15 gold badges61 silver badges123 bronze badges
answered Mar 26 at 4:27
Stein ÅsmulStein Åsmul
24.3k15 gold badges61 silver badges123 bronze badges
answered Mar 26 at 4:27
Stein ÅsmulStein Åsmul
24.3k15 gold badges61 silver badges123 bronze badges
24.3k15 gold badges61 silver badges123 bronze badges
Thank you for the info.. the thing is it is not WIX, but Visual Studio Setup Project (vdproj). With WIX one could simply do it all "by hand" and avoid auto-com-extraction. Also, it's not really a VB6 component, but a .NET assembly that has a reference to STDOLE.. For now yes, just removing these entries with "fix" script..
– Nikolay
Mar 26 at 13:00
I guess you could just register the COM stuff via the registry table instead of the COM-tables if you have to. Provided the registration remains stable and isn't generated on every build of the dll you could then make do with the same registry data for every release. Let me have a look in Visual Studio.
– Stein Åsmul
Mar 26 at 14:28
add a comment |
Thank you for the info.. the thing is it is not WIX, but Visual Studio Setup Project (vdproj). With WIX one could simply do it all "by hand" and avoid auto-com-extraction. Also, it's not really a VB6 component, but a .NET assembly that has a reference to STDOLE.. For now yes, just removing these entries with "fix" script..
– Nikolay
Mar 26 at 13:00
I guess you could just register the COM stuff via the registry table instead of the COM-tables if you have to. Provided the registration remains stable and isn't generated on every build of the dll you could then make do with the same registry data for every release. Let me have a look in Visual Studio.
– Stein Åsmul
Mar 26 at 14:28
Thank you for the info.. the thing is it is not WIX, but Visual Studio Setup Project (vdproj). With WIX one could simply do it all "by hand" and avoid auto-com-extraction. Also, it's not really a VB6 component, but a .NET assembly that has a reference to STDOLE.. For now yes, just removing these entries with "fix" script..
– Nikolay
Mar 26 at 13:00
Thank you for the info.. the thing is it is not WIX, but Visual Studio Setup Project (vdproj). With WIX one could simply do it all "by hand" and avoid auto-com-extraction. Also, it's not really a VB6 component, but a .NET assembly that has a reference to STDOLE.. For now yes, just removing these entries with "fix" script..
– Nikolay
Mar 26 at 13:00
I guess you could just register the COM stuff via the registry table instead of the COM-tables if you have to. Provided the registration remains stable and isn't generated on every build of the dll you could then make do with the same registry data for every release. Let me have a look in Visual Studio.
– Stein Åsmul
Mar 26 at 14:28
I guess you could just register the COM stuff via the registry table instead of the COM-tables if you have to. Provided the registration remains stable and isn't generated on every build of the dll you could then make do with the same registry data for every release. Let me have a look in Visual Studio.
– Stein Åsmul
Mar 26 at 14:28
add a comment |
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
Got a question that you can’t ask on public Stack Overflow? Learn more about sharing private information with Stack Overflow for Teams.
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%2f55346620%2fvisual-studio-setup-project-vdproj-stdole-how-to-properly-register-com-dll%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
Is this a VB6 COM dll? Is it a public DLL that you can put somewhere to look at? Maybe it is even a standard dll? Perhaps it is not even necessary to add?
– Stein Åsmul
Mar 26 at 1:02
It is a .NET assembly (that uses some things defined in the STDOLE). It's closed source, so I can't change this dependency :[
– Nikolay
Mar 26 at 13:05
So it must be a .NET assembly that is registered for COM interop then? It has been a while since I worked on that. Are there COM components in there as well (dlls, ocx, etc...)?
– Stein Åsmul
Mar 26 at 14:18
Correct, this is a .NET assembly to be registered for COM interop. Please note that this one is not "Primary Project Output" causing the issue, but a dependent assembly (that is auto-populated by the vdproj extension, under the "dependencies" list).
– Nikolay
Mar 26 at 14:39
Updated my answer last night. The registry table approach will cause some validation issues, but it should work OK. I do believe registering the component prior to building should eliminate the registry key as well. Haven't tested.
– Stein Åsmul
Mar 27 at 12:23