.NET Framework - vs2005 on win7

Asked By RobcPetti on 01-Aug-12 03:24 PM
Hi, I have installed vs2005 on win7 with sp1. Followed all info to update to =
use with=20
win7. I am trying to use a metalib.dll with my project. Basically this opens=
a directory to show metastock files. When I run the program I get System a=
ccess violation. So ive tried this on another pc with xp, no problems at al=
l. I have also tried on my laptop with win 7 and get the same error. Ive done=
a clean install of win 7, there is very little on the pc now. Any ideas at=
all. I am hoping I have missed something basic when updating vs2005. I have ins=
talled both service packs for vista and win 7.
Regards Robert

Anders Eriksson replied to RobcPetti on 01-Aug-12 04:40 PM
Probably a permission problem.
Test by turning of UAC

// Anders

English is not my first language.
So any error or strangeness is due to the translation.
Please correct my English so that I may become better.
Arne_Vajhøj replied to RobcPetti on 01-Aug-12 08:58 PM
32 or 64 bit Win7?

As far as I can google then metalib is COM and therefore
native code and tied to 32 bit.

If it is a 64 bit Win and .NET CLR startup in 64 bit then
something bad will happen.

Marcel_Müller replied to Arne_Vajhøj on 02-Aug-12 03:20 AM
You might be right with respect to metalib. But there is no general
restriction that a COM object must have the same word width than the
caller. The entire Visual Studio is only 32 bit, including newer
versions. But COM is always a source of curios permission problems. It
is almost unpredictable in this subject.

Brian Cryer replied to Anders Eriksson on 02-Aug-12 04:39 AM
If it is a UAC issue then an alternative to turning UAC off is not to
install to "C:\Program Files", but somewhere else. I install "older"
software to "C:\Program Files (Open)" - there is nothing special about the
name, it just reminds me that its similar to "C:Program Files" but different
because there are no UAC issues. It works great for the older software I use
where this would otherwise be an issue.
Brian Cryer
RobcPetti replied to Brian Cryer on 02-Aug-12 02:40 PM
Hi, thankyou for your replys. Ive tried turning of uac, and installing in a different area. Im using 32 bit. Still no joy. I am hoping metalib can help, no joy so far. Why would this not be an issue with xp.
Regards Robert
RobcPetti replied to RobcPetti on 02-Aug-12 04:48 PM
Out of curiosity i tried this with vs2010 express and have the same problem. It seem to be something to do with protected memory.
Regards Robert
Arne_Vajhøj replied to RobcPetti on 02-Aug-12 06:49 PM
Maybe it is a bad lib that just does not work with newer Windows?

Do you have the latest version of the lib?

Arne_Vajhøj replied to Marcel_Müller on 02-Aug-12 06:52 PM

If we are talking "in process" calls, then all the usual
restriction should apply - in short: same bitnesx required.


If VS is written in .NET and uses 32 bit COM modules, then
all that is required is to get it marked as target platform
x86 instead of any.

Peter Duniho replied to Arne_Vajhøj on 02-Aug-12 08:41 PM
Two things:

Marcel may be referring to the fact that not all COM servers are "in-proc".
Maybe metalib is (I did not look), but an out-of-proc COM server need not
match the platform type as the client.

Also, I will also point out the wording in your post, which seemed to be
saying that simply being COM of any sort requires 32-bit.  I.e. "metalib is
COM and therefore...tied to 32 bit".

I assume what you really meant is that metalib is itself 32-bit native
code, and therefore tied to 32-bit.  That's just not what the sentence you
wrote seems to say.  And in any case, if metalib offers an out-of-proc
server mode, then it can be 32-bit and still interop with 64-bit processes.

Brian Cryer replied to RobcPetti on 03-Aug-12 07:16 AM
Whilst it might seem a little defeatest, if it works on XP but not Windows
7, then why not install it in the XP Virtual Machine? If you have not got the
XP Virtual Machine it is a free download from Microsoft (not sure where,
you will have to google for it). Once you have that then try installing in
there, after all it is one of the reasons why Microsoft have provided it.
Brian Cryer
Peter Duniho replied to Brian Cryer on 03-Aug-12 12:05 PM
Noting, however, that "XP Mode" (which is what you are talking about, is
available only on the higher-priced versions of Windows. "Ultimate" for
sure, and I think it might be free on "Professional" too.

Web search for "virtual pc xp mode" will turn up useful information there.

Gene Wirchenko replied to Peter Duniho on 03-Aug-12 01:07 PM

It is on 7 Professional.  I have never used it, but it is there.


Gene Wirchenko
Arne_Vajhøj replied to Peter Duniho on 03-Aug-12 09:05 PM
Professional, Enterprise and Ultimate has it.

RobcPetti replied to Arne_Vajhøj on 04-Aug-12 04:13 PM
Thank you all for your replies. I have not managed to resolve it on windows=
7. What I have done is to use my XP pc, which I remote into. I am awaiting =
a solution from the makers of metalib in the mean time. I tried virtual pc,=
but couldnt get vs2005 to install correctly.
Regards Robert
Arne_Vajhøj replied to RobcPetti on 04-Aug-12 05:33 PM
VS2005 should install on WinXP (with .NET 2.0 or newer).

But you should be able to build on Win7 and just run on WinXP.

Arne Vajhøj replied to Peter Duniho on 04-Aug-12 06:00 PM
Which is why I made the condition.

But given that the original post explicit said that it was a DLL
and not an EXE, then that condition should be true.

Unless of course DllHost.exe is being used.

Now you are talking about the first comment not the last.

You are correct that if it is a 64 bit COM DLL, then it is not
tied to 32 bit but tied to 64 bit.

But until Windows 8 becomes popular, then 64 bit COM is relative rare.

My "tied to 32 bit" without qualification comment was still wrong