I may need to set things up in two builds. I was already planning to try your suggestion as I felt that would be the easiest way to handle most of the current problems. At least I wanted to try it so that I could show my co-workers how it works this way and hopefully convince them of the changes required... That persuasion will be difficult.
I do have another problem. To try this I chose a single project and put it under a new VSS db on my local machine (so that I can test without messing up the real db). I also needed to bring over two other projects over that are referenced (the source code requires a few include files). Of course the build failed because VS.NET could not find the include files. This sort of situation appears many times in the over all library. We use a number of resources that are not part of our projects but they live in the same repository. Since they are not in the same tree Draco never gets them from source control. I thought a way to get this to work could be to use NAnt to get all the extra required sources from VSS, but then I would need to build with NAnt which doesn't build VC++ projects correctly. This one is tough because as difficult as it will be to move the other sources these sources would be near impossible since they "live" outside our domain. Again, I welcome suggestions! I was hoping to get some creative ideas to work around the "fragmented" code, but it seems I will need to restructure the code. Thanks! -- Edwin G. Castro Firing Systems Engineer [EMAIL PROTECTED] -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nick Robinson Sent: Tuesday, March 16, 2004 1:35 AM To: [EMAIL PROTECTED] Subject: Re: [Draconet-users] Draco.NET, VSS, and VS.NET 2003 Edwin, I am sorry to hear you are having such difficulties in getting your CI solution implemented. I have found it is sometimes difficult retro-fitting into well-established build environments. However all may not be lost. I am going to make a few suggestions apropos your overall problem, and I appreciate they might not be helpful. You say you cannot restructure, but without doing this, you are going to cause yourself more pain... 1. Accept that to achieve what you want to achieve CI wise, some restructuring *is* required. You have to be creative, and it might involve some effort - but it will be worth it. 2. Create a single global project in VSS and relocate all the sub-projects under this new project. Draco.NET can then track changes underneath this global project - this achieves your tracking problem, but at the expense of restructuring your projects. Obviously you wont want to lose your history for your source, so I would simply do a clean Get Latest of everything that is the latest code, then relocate that on my computer under the new project directory. Finally I would check in this new source project. 3. Remote VSS db: I am not sure what the problem is with this. At my shop, we have a remote DB stored on a GLP protected server managed by HP many miles away. I am sure this is a security issue Edwin, so maybe we can take a look at that. I had a leftfield idea, but it was frought with problems. Maybe someone else has a good idea. Warm regards, nick robinson site : http://www.fromconcept.co.uk weblog : http://www.fromconcept.co.uk/weblog.aspx "Castro, Edwin Gabriel (Firing Systems Engr.)" <[EMAIL PROTECTED]> wrote: I spent the last few months trying to build an automated build utility = for my group's projects at work. The other day I saw an article on = Continuous Integration and found Draco.NET which seemed to do what I = wanted to do better than what I could ever do myself. Unfortunately, = Draco.NET still does not do everything I need it to do. Instead of = diving into the code and trying to implement everything I decided to ask = in the mailing list. I posted a message on the SourceForge forum but it = doesn't seem like anyone has read it. A little background first... My group at work is building a library composed of 37 Visual C++ = projects, 6 Visual C# projects, and 4 Visual Basic projects distributed = over 3 Visual Studio .NET 2003 solutions. Most of these projects (and = solutions) began as Visual Studio 6.0 (or earlier) entities that have = morphed (converted to new formats) through time. The sources are not located under a single source tree so tracking the = source will require tracking many directories. Fortunately, all the = sources reside in the same source control database. We use Visual = SourceSafe (and SourceOffSite) for source control. So far I've installed Draco.NET and successfully built projects stored = in a local VSS database. I'm having problems accessing the remote VSS = database. I read that having Draco.NET run under a Domain account with = access to the server would fix the problem but that hasn't worked (or I = did it wrong). My next major problem is that I really don't have a way to reorganize = the source code under source control. This means that I really need the = ability to track multiple VSS projects and rebuild when any of those = sources changes. Also, I need all 3 solutions to be built! There are = some technical reasons (which, I admit, I don't fully understand) that = demand that our sources be separated into 3 solutions. Another part of my job here is to establish some regression tests for = this library. It is very likely that these tests would all be located on = their own solution. This means I need a way to compile everything (4 = solutions in multiple VSS projects) and execute the tests. I looked into = using something like NAnt but it won't build my VC++ projects. Since = most of my projects are VC++ projects NAnt is mostly useless. I guess what I really need are suggestions. I can't change the way the = code is structured and I need to base my CI solution around VS.NET 2003 = solutions. Trying to build the projects individually using NAnt is too = much effort when VS.NET already does it for us. Managing both ways side = by side will create huge headaches as no one will remember to update the = NAnt scripts! I really do welcome suggestions. I just need creative ones to get around = the particular problems I have. Suggestions which require the = "forbidden" changes mentioned above won't help me. That said, thanks for = your help and keep doing a good job. Draco.NET is a great CI solution! = (It just doesn't work well with this nine year old library...) -- Edwin G. Castro Firing Systems Engineer [EMAIL PROTECTED] > ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470&alloc_id=3638&op=click _______________________________________________ Draconet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/draconet-users ------------------------------------------------------- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70&alloc_id638&op=click _______________________________________________ Draconet-users mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/draconet-users