Kinook Software Forum

Go Back   Kinook Software Forum > Visual Build Professional > [VBP] User Tips, Tricks and Samples
FAQ Community Calendar Today's Posts Search

Reply
 
Thread Tools Rate Thread Display Modes
  #1  
Old 10-15-2009, 06:57 AM
trailway trailway is online now
Registered User
 
Join Date: 04-07-2009
Posts: 26
Incremental builds

I have Visual Build project which consists of a set of Visual Studio build steps. For the sake of argument, let's say that there are 3 steps which build DLLs such at 3 depends on 2 and 2 depends on 1. So... the steps are built in order 1, 2, 3 - no problem.

The thing that I want to do is to move to an incremental build process, i.e. only build if required. That is certainly possible using in Visual Build and Visual Studio. When a component builds what actually happens is that Visual Studio unregisters the previous component, builds it, and then reregisters it.

The problem I have is that the unregistration can fail. For example, if I change an interface in component 1 then when component 3 tries to unregister the previous version it will fail in Visual Studio. The failure can be overcome but it breaks my automated build process which is unacceptable.

I get errors like "c:\WINDOWS\Microsoft.NET\Framework\v3.5\Microsoft .Common.targets(928,9): error MSB3395: Cannot unregister assembly...".

I am thinking that the only option is to unregister everything at the start and then have an explicit register step after each Visual Studio step. That way I can be sure that the component is registered whether or not it built.

Am I in the weeds? Any suggestions?
Reply With Quote
  #2  
Old 10-15-2009, 07:15 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
Some possibilities: http://www.google.com/search?q=error...ister+assembly
Reply With Quote
  #3  
Old 10-15-2009, 07:49 AM
trailway trailway is online now
Registered User
 
Join Date: 04-07-2009
Posts: 26
I do not believe that the error is a Microsoft bug. I think that it is simply a dependency ordering problem and wondered if anyone else had developed some technique to handle this pattern.

This is the bld file which is a set of 3 Visual Studio build steps
1) Unregister1, build1, register1
2) Unregister2, build2, register2
3) Unregister3, build3, register3

The unregister, build, register is what Visual Studio itself does when the Visual Build step executes.

In order to rebuild this what I think I need is:
1) Unregister * (3 then 2 then 1)
2) Build 1
3) Register 1
4) Build 2
5) Register 2
6) Build 3
7) Register 3

Note that I have to have a register step after each build step because the build is conditional in the sense that it may not execute because it is already update-to-date.

Does anyone else do this?
Reply With Quote
  #4  
Old 10-15-2009, 09:12 AM
kinook kinook is online now
Administrator
 
Join Date: 03-06-2001
Location: Colorado
Posts: 6,034
I think you could achieve this by disabling 'Register for COM Interop', using the COM Register+Process Files actions in VBP to unregister, and calling RegAsm.exe to register from post-build events in VS.
Reply With Quote
  #5  
Old 10-22-2009, 10:52 AM
trailway trailway is online now
Registered User
 
Join Date: 04-07-2009
Posts: 26
Does anyone know if there is a way that I can pass a parameter to MSBuild which tells is to execute the UnmanagedRegistration target?

What I like to have is a "Make VS 2008" build step which builds only if required but always registers for COM interop if this was set in the project.

In order to understand this, I tried to just add an MSBuild build step with this target but executing it did not do the registration. I also tried setting the Platform and Configuration properties but that did not cut it as well. I'm thinking that the problem relates to the dependency machine but I am such a MSBuild newbie that the answer is not obvious to me.
Reply With Quote
  #6  
Old 10-23-2009, 08:01 AM
trailway trailway is online now
Registered User
 
Join Date: 04-07-2009
Posts: 26
I figured my problem out. Visual Studio creates a file ProjectName.csproj.UnmanagedRegistration.cache and the existence of this file implies that the project has already performed registration. So, simply removing the file and then building causes Visual Studio to register it again.

All this logic is in the Microsoft.Common.targets file which the MSBuild uses.
Reply With Quote
Reply


Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



All times are GMT -5. The time now is 01:57 PM.


Copyright © 1999-2023 Kinook Software, Inc.