2

We have a mixed mode DLL written in C++ which wraps native C++ DLLs and exposes managed classes. In the exposed managed classes, we use method arguments of type Vector3D etc., which are part of PresentationCore.DLL.

Therefore, the mixed mode C++ code needs to reference PresentationCore.DLL. We do this via

#using <PresentationCore.dll>

which requires the project's search path to include the folder PresentationCore.dll lives in.

This is bad, because these folders vary on different machines, and our projects need to compile without changes on several machines. At the moment, we have solved this by including a copy of PresentationCore.dll in our code repository, which is obviously not a good solution.

I'd be grateful for suggestions how we can get around specifying an explicit path to a DLL that should be perfectly accessible via GAC.

Some programmer dude
  • 400,186
  • 35
  • 402
  • 621
user816098
  • 262
  • 3
  • 14
  • Isn't presentationcore in the GAC? V3 and V4 (x86 and AMD 64) are in my GAC. Do you need to add a search path for the GACed assemblies in MC++ – Preet Sangha Jan 17 '12 at 08:42
  • Yes, it is in the GAC. However, the C++ compiler doesn't seem to look there, as the using statement will fail if the dll isn't also in a directly searched path. – user816098 Jan 17 '12 at 08:47

3 Answers3

0

Phew I got it working. I have a native project and I had the same issue, I need to use HwndSource from PresentationCore, to do some analysis on hwnds. What I did was to leave my project as native (no /clr switch), then for my source file which had the function that used HwndSource I added the /clr switch, that way I can contain the settings for other sources, like exception handling and such.

#using <System.dll>
#using <WindowsBase.dll>
#using <PresentationFramework.dll>
#using <PresentationCore.dll>
#using <UIAutomationProvider.dll>
#using <UIAutomationTypes.dll>

This works just fine, you will just won't get any Intellisense support. And some warnings in the output, if you can live with that, this is for you.

0

Don't do #using <PresentationCore.dll>. You need to right click on the project, go to References..., click Add New Reference... and pick PresentationCore from the .Net tab. I got the hint from:

http://msdn.microsoft.com/en-us/library/aa970266.aspx

seeker
  • 1,136
  • 1
  • 13
  • 16
-1

The GAC is found in %windir%\Assembly\ then the subdirectory GAC_32 or GAC_64

In a situation like this I would use a symbolic link. Create a link to the DLL in the local directory. Then compile from that link.

Yes you have to change it for each machine. But all you have to do is a single line of batch script to do it.

Consider this running on my machine.

C:\temp>for /f "tokens=*" %f in ('dir \windows\assembly\presentationcore.dll  /s/b') do @echo %f
C:\windows\assembly\GAC_32\PresentationCore\3.0.0.0__31bf3856ad364e35\PresentationCore.dll
C:\windows\assembly\GAC_64\PresentationCore\3.0.0.0__31bf3856ad364e35\PresentationCore.dll

Pick the one you need (say GAC_64) and set a link to it- this all you should need.

@for /f "tokens=*" %f in ('dir \windows\assembly\presentationcore.dll  /s/b') do @echo %f | @findstr GAC_64 | mklink .\presentationCore.dll "%f"
Preet Sangha
  • 64,563
  • 18
  • 145
  • 216
  • *Never* reference assemblies from the GAC in your project. The GAC is a deployment detail. The copies of the assemblies in the GAC are *not* the same as the reference assemblies, especially since .NET 4. – Hans Passant Jan 22 '12 at 09:10
  • @HansPassant Thanks - can you provide a reference for that please. – Preet Sangha Jan 22 '12 at 09:19