Eh, that wasn't the answer I was hoping for; I was hoping it would be a
straight 1:1 conversion from our .vdproj project over to our .wixproj.
Currently the .vdproj defines the reference like this:
"AssemblyRegister" = "3:1"
"AssemblyIsInGAC" = "11:TRUE"
"AssemblyAsmDisplayName" =
"8:Microsoft.ReportViewer.ProcessingObjectModel, Version=8.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a, processorArchitecture=MSIL"
"ScatterAssemblies"
{
"_757E3A9FF837C1D92380AD581B054907"
{
"Name" =
"8:Microsoft.ReportViewer.ProcessingObjectModel.dll"
"Attributes" = "3:512"
}
}
"SourcePath" = "8:Microsoft.ReportViewer.ProcessingObjectModel.dll"
"TargetName" = "8:"
"Tag" = "8:"
"Folder" = "8:_C60F11269B2A4BD9B554C5B92230BB59"
"Condition" = "8:"
"Transitive" = "11:FALSE"
"Vital" = "11:TRUE"
"ReadOnly" = "11:FALSE"
"Hidden" = "11:FALSE"
"System" = "11:FALSE"
"Permanent" = "11:FALSE"
"SharedLegacy" = "11:FALSE"
"PackageAs" = "3:1"
"Register" = "3:1"
"Exclude" = "11:FALSE"
"IsDependency" = "11:TRUE"
"IsolateTo" = "8:"
I'm assuming it's querying the assmebly cache, then, in visual studio to
resolve the references. It's pretty simple to query the Assembly Cache using
Fusion.dll API calls. I just wrote an app in about 30 minutes to do just that
using the following calls:
<DllImport("fusion.dll")> _
Friend Shared Function CreateAssemblyEnum(ByRef ppEnum As
IAssemblyEnum, ByVal pUnkReserved As IntPtr, ByVal pName As IAssemblyName,
ByVal flags As AssemblyCacheFlags, ByVal pvReserved As IntPtr) As Integer
End Function
<DllImport("fusion.dll")> _
Friend Shared Function CreateAssemblyNameObject(ByRef ppAssemblyNameObj
As IAssemblyName, <MarshalAs(UnmanagedType.LPWStr)> ByVal szAssemblyName As
String, ByVal flags As CreateAssemblyNameObjectFlags, ByVal pvReserved As
IntPtr) As Integer
End Function
<DllImport("fusion.dll")> _
Friend Shared Function CreateAssemblyCache(ByRef ppAsmCache As
IAssemblyCache, ByVal reserved As Integer) As Integer
End Function
<ComImport(), InterfaceType(ComInterfaceType.InterfaceIsIUnknown),
Guid("e707dcde-d1cd-11d2-bab9-00c04f8eceae")> _
Friend Interface IAssemblyCache
'PreserveSig() Indicates that the HRESULT or retval signature
transformation that takes place during COM interop calls should be suppressed
<PreserveSig()> _
Function UninstallAssembly(ByVal flags As Integer,
<MarshalAs(UnmanagedType.LPWStr)> ByVal assemblyName As String, ByVal refData
As InstallReference, ByRef disposition As AssemblyCacheUninstallDisposition) As
Integer
<PreserveSig()> _
Function QueryAssemblyInfo(ByVal flags As Integer,
<MarshalAs(UnmanagedType.LPWStr)> ByVal assemblyName As String, ByRef
assemblyInfo As AssemblyInfo) As Integer
<PreserveSig()> _
Function Reserved(ByVal flags As Integer, ByVal pvReserved As IntPtr,
ByRef ppAsmItem As [Object], <MarshalAs(UnmanagedType.LPWStr)> ByVal
assemblyName As String) As Integer
<PreserveSig()> _
Function Reserved(ByRef ppAsmScavenger As [Object]) As Integer
<PreserveSig()> _
Function InstallAssembly(ByVal flags As Integer,
<MarshalAs(UnmanagedType.LPWStr)> ByVal assemblyFilePath As String, ByVal
refData As InstallReference) As Integer
End Interface
Any chance this could be included in a future release? To our company, this
proves to be a major issue currently in converting from our .vbproj to .wixproj
for MSM building.
Thanks,
Doug
-----Original Message-----
From: David Watson [mailto:dwat...@sdl.com]
Sent: Thursday, April 07, 2011 10:09 AM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Building with a .dll from GAC
Hi,
The best way of doing this is exactly what you think is a bad idea. Store
this dll in a well know location or source control and refer to it as part of
your build process.
The Gac is actually a more complex structure than it appears in the
simplified windows explorer view. You can investigate it from a command
prompt if you feel the need.
For example I have a version of the dll in
"c:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.ProcessingObjectModel\10
.0.0.0__b03f5f7f11d50a3a"
I would of course check the legality of shipping this dll in your setup as it
may not be allowed as microsoft have a redist for it. You may need to bundle
this as a pre-requisite.
2010 version.
http://www.microsoft.com/downloads/en/details.aspx?FamilyID=a941c6b2-64dd-4d0
3-9ca7-4017a0d164fd
Dave
-----Original Message-----
From: Brinkmeier, Doug [mailto:doug.brinkme...@countryfinancial.com]
Sent: 07 April 2011 15:43
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Building with a .dll from GAC
I've been doing some research, and seeing a lot of posts about installing a
.dll to the GAC, but (at least to me) it seems like the much more common
scenario is just simply using a known .dll/assembly name installed in the GAC
in the build (just to deploy to the install directory). I won't know exact
location of the .dll, because this will be built on different machines, and
the exact location of the .dll will not be known. But, we can assume it is
installed in the GAC only. I've tried a number of different things, and
nothing has worked yet. Here is the component:
<Component Id="MICROSOFT.REPORTVIEWER.PROCESSINGOBJECTMODEL.DLL"
DiskId="1" Guid="939B1998-7A72-4D45-8269-9DEB5F1C6405">
<File Id="MICROSOFT.REPORTVIEWER.PROCESSINGOBJECTMODEL.DLL"
KeyPath="yes" Name="Microsoft.ReportViewer.ProcessingObjectModel"
Source="$(env.WINDIR)\assembly\Microsoft.ReportViewer.ProcessingObjectModel.d
ll" />
</Component>
I've also tried:
Source="Microsoft.ReportViewer.ProcessingObjectModel.dll"
This particular .dll is not installed on the hard drive anywhere, and only
exists in the GAC. I could hack around the issue by dropping it out to a
known location, but that's not very clean; I assume there should be a pretty
easy way to reference a .dll in the GAC, but I'm just not finding any
documentation on it.
Thanks,
Doug
-----------------------------------------------------------------------------
-
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires
that you delete it without acting upon or copying any of its contents, and we
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY,
UK.
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
_______________________________________________
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
