Re: [WiX-users] Patch building with Torch, all .NET assemblies "changed"
We are handling this scenario via automated query against a source control repository, rather than at a binary level of the compiled output. We investigated compiled output comparison as well, and it just was not a feasible solution for us. We handled this with a service account that checks-in the version # into the notes in SVN when a build is performed on our build server. We keep our build server locked-down to contain our "binding" between the compiled output and the source code changes. We use standard naming conventions (project outputs .dll) to make it easy to see which .dlls have changed since release X. It's not perfect, but it works for us. The keys are locking-down the build server, using a service account, and keeping track of source-code to binary output mappings (or enforcing a naming convention to do this). We are using SVN as source control and Jenkins as our build server. Good luck! -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: Thursday, January 26, 2012 3:34 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch building with Torch, all .NET assemblies "changed" When I was at SCX (Microsoft), we went so far as to investigate tools to compare only the "code" parts of an assembly--but in the end, that proved too cumbersome and unreliable, and so we just lived with the diff's between build. At ESA-JHA, a significant number of assemblies are checked into source control when they are updated using special, manual "promote" builds. These assemblies are thus not rebuilt except when they change--reducing the diff's in builds. But, an all-up complete rebuild is also sacrificed by this technique. There are always compromises. -- John Merryweather Cooper Build & Install Engineer - ESA Jack Henry & Associates, Inc.(r) Shawnee Mission, KS 66227 Office: 913-341-3434 x791011 jocoo...@jackhenry.com www.jackhenry.com -Original Message- From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com] Sent: Thursday, January 26, 2012 3:14 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Patch building with Torch, all .NET assemblies "changed" My initial guess is that your assembly's versions are changing between builds. I'm very interested in a proposed approach to this as we have a build that results in changed versions on every build. I haven't personally investigated an approach to handle this yet. I haven't had the time yet to do it. Edwin G. Castro Software Developer - Staff Digital Channels Fiserv Office: 503-746-0643 Fax: 503-617-0291 www.fiserv.com P Please consider the environment before printing this e-mail > -Original Message- > From: john.burak [mailto:john.bu...@telvent.com] > Sent: Thursday, January 26, 2012 11:00 AM > To: wix-users@lists.sourceforge.net > Subject: [WiX-users] Patch building with Torch, all .NET assemblies "changed" > > We recently implemented patch building using Torch/Pyro. We are > keeping the old MSI and totally rebuilding a new one for Torch to diff > with. The problem is that Torch sees all of our .NET assemblies as > changed even though the source code only changed in a few. We did > some digging and it turns out that if we recompile an assembly with > the same source code, the binary result (DLL or EXE) is different from > the first build. Perhaps it's putting a date stamp inside. Our guess > is that Torch is doing a binary comparison and sees the file as > changed. We need a patch with only the few files who's source code has > changed. > > So the question is, how do people handle this situation? We could try > to change our build process so that we don't rebuild every project the > second time (let MSBuild pick just the changed ones), but then we won't get > "clean" > builds and we won't detect circular references between assemblies > (developers sometimes accidentally do that). We can limit the impact > by doing a non-clean build for only the patch. This may be the only > option, but I wanted to get some opinions first. Maybe there is something > I'm missing here. > > Thanks for your input! > > - John > > -- > View this message in context: http://windows-installer-xml-wix- > toolset.687559.n2.nabble.com/Patch-building-with-Torch-all-NET-assembl > ies- > changed-tp7227881p7227881.html > Sent from the wix-users mailing list archive at Nabble.com. > > -- > Keep Your Developer Skills Current with LearnDevNow! > The most comprehensive online learning library for Microsoft > developers is just $99.99! Visual Studio, SharePoint, SQL - plus > HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you > subscribe now! > http://p.sf.net/sfu/learndevnow-d2d > ___ > WiX-users mailing list > WiX-users@lists.sourceforge.net > https://l
Re: [WiX-users] Building with a .dll from GAC
Yes, I've seen this, and this was also just an example reference - the general
case is "referencing a .dll that is known to be installed only to the GAC".
-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Thursday, April 07, 2011 12:12 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Building with a .dll from GAC
This may help if you've not seen it.
http://msdn.microsoft.com/en-us/library/ms251723.aspx
-Original Message-----
From: Brinkmeier, Doug [mailto:doug.brinkme...@countryfinancial.com]
Sent: 07 April 2011 18:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Building with a .dll from GAC
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:
_
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
_
Friend Shared Function CreateAssemblyNameObject(ByRef
ppAssemblyNameObj As IAssemblyName, ByVal
szAssemblyName As String, ByVal flags As CreateAssemblyNameObjectFlags, ByVal
pvReserved As IntPtr) As Integer
End Function
_
Friend Shared Function CreateAssemblyCache(ByRef ppAsmCache As
IAssemblyCache, ByVal reserved As Integer) As Integer
End Function
_
Friend Interface IAssemblyCache
'PreserveSig() Indicates that the HRESULT or retval signature
transformation that takes place during COM interop calls should be suppressed
_
Function UninstallAssembly(ByVal flags As Integer,
ByVal assemblyName As String, ByVal refData
As InstallReference, ByRef disposition As AssemblyCacheUninstallDisposition)
As Integer
_
Function QueryAssemblyInfo(ByVal flags As Integer,
ByVal assemblyName As String, ByRef
assemblyInfo As AssemblyInfo) As Integer
_
Function Reserved(ByVal flags As Integer, ByVal pvReserved As IntPtr,
ByRef ppAsmItem As [Object], ByVal
assemblyName As String) As Integer
_
Function Reserved(ByRef ppAsmScavenger As [Object]) As Integer
_
Function InstallAssembly(ByVal flags As Integer,
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 refe
Re: [WiX-users] Building with a .dll from GAC
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:
_
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
_
Friend Shared Function CreateAssemblyNameObject(ByRef ppAssemblyNameObj
As IAssemblyName, ByVal szAssemblyName As
String, ByVal flags As CreateAssemblyNameObjectFlags, ByVal pvReserved As
IntPtr) As Integer
End Function
_
Friend Shared Function CreateAssemblyCache(ByRef ppAsmCache As
IAssemblyCache, ByVal reserved As Integer) As Integer
End Function
_
Friend Interface IAssemblyCache
'PreserveSig() Indicates that the HRESULT or retval signature
transformation that takes place during COM interop calls should be suppressed
_
Function UninstallAssembly(ByVal flags As Integer,
ByVal assemblyName As String, ByVal refData
As InstallReference, ByRef disposition As AssemblyCacheUninstallDisposition) As
Integer
_
Function QueryAssemblyInfo(ByVal flags As Integer,
ByVal assemblyName As String, ByRef
assemblyInfo As AssemblyInfo) As Integer
_
Function Reserved(ByVal flags As Integer, ByVal pvReserved As IntPtr,
ByRef ppAsmItem As [Object], ByVal
assemblyName As String) As Integer
_
Function Reserved(ByRef ppAsmScavenger As [Object]) As Integer
_
Function InstallAssembly(ByVal flags As Integer,
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
-Or
[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: 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
