Adding a reference to a COM in VS2008

  • Thread starter Thread starter BrassicaNigra
  • Start date Start date
B

BrassicaNigra

Greetings,

Recently I upgraded to Windows Vista Ultimate and VS2008 with SQLExpress
2008. For the last several years I have been using Windows XP SP2 and VS2005
with SQLExpress 2005. All of the applications that I have been working on
for my clients have come over beautifully with one exception.

Most of my applications make use of references that are either part of the
CLR or are COMs. One of the COM applications installs fine, I can load and
start the software from the Start menu, but when I try to see the COM in the
Add Reference dialog, it does not appear. It is there on my XP machine.

Why would this program install and work fine and I can't see the COM
interface?

TIA,

Dale
 
BrassicaNigra said:
Greetings,

Recently I upgraded to Windows Vista Ultimate and VS2008 with SQLExpress
2008. For the last several years I have been using Windows XP SP2 and
VS2005
with SQLExpress 2005. All of the applications that I have been working on
for my clients have come over beautifully with one exception.

Most of my applications make use of references that are either part of the
CLR or are COMs. One of the COM applications installs fine, I can load
and
start the software from the Start menu, but when I try to see the COM in
the
Add Reference dialog, it does not appear. It is there on my XP machine.

Why would this program install and work fine and I can't see the COM
interface?
Click to expand...

Maybe, it's due to UAC and Virtualization stepping in and redirecting files
elsewhere, when it comes to C:\Program Files and C:\Windows, which could be
placed in hidden system folders.

http://juice.altiris.com/article/2665/folder-virtualization-concepts-windows-vista
 
Good morning Dale and Mr. Arnold.

I basically agree with Mr. Arnold that this issue might be caused by
"Virtualization" in Vista. Mark Russinovich had a good presentation about
UAC and "Virtualization" at
http://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid=360.
Another possible cause is that the COM component was written in .NET
because I once saw several cases where .NET COM component does not appear
in COM tab. Dale, I will focus on "Virtualization" in this reply. If you
COM component was indeed written in .NET, please let me know, and I will do
more researches on that focus in the next reply.

"Virtualization" was introduced into Vista for backwards compatibility.
Many pre-Vista softwares run as a full admin privilege and write to
C:\Windows\, C:\Program Files\ or HKLM/HKCR registry at ease, however Vista
(UAC on) does not allow this kind of operation without elevation. In order
that these pre-Vista applications are still able to run in Vista without a
complete re-design, Vista provides the "Virtualization" feature to
transparently redirect the legacy program's operations on C:\ dir or HKLM
reg to the user profile folder or HKCU. These redirections are only visible
to the legacy app with "Virtualization" turned on. Non-legacy programs
(e.g. Visual Studio) are blind to it and regard C:\ dir and the redirection
folder in the user profile as two different places. Therefore, this can
possibly explain the symptom you see: an app (I guess it's an pre-Vista
app) is able to consume a COM component, but Visual Studio cannot recognize
it in the "Add Reference" dialog/"COM" tab.

Apart from the file-system redirection for the C:\Windows\ and C:\Program
Files directories mentioned by Mr. Arnold. The registry redirection of the
COM component may also be the reason. For example, the COM component might
be installed by a legacy installer (whose Virtualization is turned on), and
its registry keys are written to the
HKEY_CURRENT_USER\Software\Classes\VirtualStore\... instead of HKCR.

Dale, may I suggest that you check the following points on your side?

1. Check whether "Virtualization" is turned on for the app that can consume
the COM component.

You can do this by starting the app, and Task Explorer. In Task Explorer,
go to View menu -> Select Columns and check "Virtualization". Then find the
app's process and see whether its "Virtualization" is "Enabled". If yes, I
think this issue is very likely to be caused by "Virtualization".

2. Try to locate the COM component's DLL to see whether it's in the User
Profile folder or not.
Per-user virtual root: %UserProfile%\AppData\Local\VirtualStore

If the COM dll is in a sub folder of the above location, it means that the
file system Virtualization is redirecting the DLL.

3. Try to locate the COM component's registry key.

You can search the ProgID in regedit.exe. If the search result is located
under HKEY_CURRENT_USER\Software\Classes\VirtualStore\... instead of
HKCR\CLSID\{...}, it means that the registry Virtualization is redirecting
the registry key of the component.

Please spend some time on verifying the above three points. The fix is
basically to move the COM dll to the right location and register the COM
component again with the elevated command "regsvr32".

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
 
<snipped>

You know there are many features Vista has that are not know from a software
developer's or computer user's standpoint on how Vista is protecting the O/S
like Virtualization being one.

Here is another one ASLR as an example, and there are more things being done
under the hood of Vista particularly when UAC is enabled to protect the
machine. For my own personal computer usage, I'll never go back to XP, and I
await to see what else is being implemented in Windows 7.

I also know that nothing is bullet proof as long as human beings are
involved, but XP doesn't have it. And XP will remain a malware magnet, as
most users continue to run on XP with full admin rights on the Internet wide
open to attack, and they are being hammered, because the Limited user
account cannot be used effectively with solutions, as opposed to Vista and
Standard user.

Hopefully, these links will be working again. They were working last week.

<http://www.securitypronews.com/news/securitynews/spn-45-20060601ASLRJoinsVistasBagOfTricks.html>

<http://technet.microsoft.com/en-us/magazine/cc162458.aspx>

Address Space Load Randomization

Despite measures like Data Execution Prevention and enhanced compiler error
checking, malware authors continue to find buffer overflow vulnerabilities
that allow them to infect network-facing processes like Internet Explorer®,
Windows services, and third-party applications to gain a foothold on a
system. Once they have managed to infect a process, however, they must use
Windows APIs to accomplish their ultimate goal of reading user data or
establishing a permanent presence by modifying user or system configuration
settings.

Connecting an application with API entry points exported by DLLs is
something usually handled by the operating system loader, but these types of
malware infection don't get the benefit of the loader's services. This
hasn't posed a problem for malware on previous versions of Windows because
for any given Windows release, system executable images and DLLs always load
at the same location, allowing malware to assume that APIs reside at fixed
addresses.

The Windows Vista Address Space Load Randomization (ASLR) feature makes it
impossible for malware to know where APIs are located by loading system DLLs
and executables at a different location every time the system boots. Early
in the boot process, the Memory Manager picks a random DLL image-load bias
from one of 256 64KB-aligned addresses in the 16MB region at the top of the
user-mode address space. As DLLs that have the new dynamic-relocation flag
in their image header load into a process, the Memory Manager packs them
into memory starting at the image-load bias address and working its way
down.

Executables that have the flag set get a similar treatment, loading at a
random 64KB-aligned point within 16MB of the base load address stored in
their image header. Further, if a given DLL or executable loads again after
being unloaded by all the processes using it, the Memory Manager reselects a
random location at which to load it. Figure 7 shows an example address-space
layout for a 32-bit Windows Vista system, including the areas from which
ASLR picks the image-load bias and executable load address.
 
Greetings,

Thank you both so much. This was very helpful. I disabled UAC, installed
the software and there was the COM library in the Add Reference list. Just
for fun I turned UAC back on and the library was still visible.

Guess I will need to learn some things about UAC and Virtualization, but for
now I am at least up and running again.

Once again, thanks for your help and information.

Dale Hoffman

"Jialiang Ge [MSFT]" said:
Good morning Dale and Mr. Arnold.

I basically agree with Mr. Arnold that this issue might be caused by
"Virtualization" in Vista. Mark Russinovich had a good presentation about
UAC and "Virtualization" at
http://www.microsoft.com/emea/spotlight/sessionh.aspx?videoid=360.
Another possible cause is that the COM component was written in .NET
because I once saw several cases where .NET COM component does not appear
in COM tab. Dale, I will focus on "Virtualization" in this reply. If you
COM component was indeed written in .NET, please let me know, and I will do
more researches on that focus in the next reply.

"Virtualization" was introduced into Vista for backwards compatibility.
Many pre-Vista softwares run as a full admin privilege and write to
C:\Windows\, C:\Program Files\ or HKLM/HKCR registry at ease, however Vista
(UAC on) does not allow this kind of operation without elevation. In order
that these pre-Vista applications are still able to run in Vista without a
complete re-design, Vista provides the "Virtualization" feature to
transparently redirect the legacy program's operations on C:\ dir or HKLM
reg to the user profile folder or HKCU. These redirections are only visible
to the legacy app with "Virtualization" turned on. Non-legacy programs
(e.g. Visual Studio) are blind to it and regard C:\ dir and the redirection
folder in the user profile as two different places. Therefore, this can
possibly explain the symptom you see: an app (I guess it's an pre-Vista
app) is able to consume a COM component, but Visual Studio cannot recognize
it in the "Add Reference" dialog/"COM" tab.

Apart from the file-system redirection for the C:\Windows\ and C:\Program
Files directories mentioned by Mr. Arnold. The registry redirection of the
COM component may also be the reason. For example, the COM component might
be installed by a legacy installer (whose Virtualization is turned on), and
its registry keys are written to the
HKEY_CURRENT_USER\Software\Classes\VirtualStore\... instead of HKCR.

Dale, may I suggest that you check the following points on your side?

1. Check whether "Virtualization" is turned on for the app that can consume
the COM component.

You can do this by starting the app, and Task Explorer. In Task Explorer,
go to View menu -> Select Columns and check "Virtualization". Then find the
app's process and see whether its "Virtualization" is "Enabled". If yes, I
think this issue is very likely to be caused by "Virtualization".

2. Try to locate the COM component's DLL to see whether it's in the User
Profile folder or not.
Per-user virtual root: %UserProfile%\AppData\Local\VirtualStore

If the COM dll is in a sub folder of the above location, it means that the
file system Virtualization is redirecting the DLL.

3. Try to locate the COM component's registry key.

You can search the ProgID in regedit.exe. If the search result is located
under HKEY_CURRENT_USER\Software\Classes\VirtualStore\... instead of
HKCR\CLSID\{...}, it means that the registry Virtualization is redirecting
the registry key of the component.

Please spend some time on verifying the above three points. The fix is
basically to move the COM dll to the right location and register the COM
component again with the elevated command "regsvr32".

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.

Note: The MSDN Managed Newsgroup support offering is for non-urgent issues
where an initial response from the community or a Microsoft Support
Engineer within 1 business day is acceptable. Please note that each follow
up response may take approximately 2 business days as the support
professional working with you may need further investigation to reach the
most efficient resolution. The offering is not appropriate for situations
that require urgent, real-time or phone-based interactions or complex
project analysis and dump analysis issues. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://support.microsoft.com/select/default.aspx?target=assistance&ln=en-us.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Click to expand...
 
Back
Top