My understanding on this at current stage is that the problem is related to the fact that I am using devenv to build through CruiseControl.NET but when I build manually VisualStudio is using msbuild. Basically this causes dependencies to be ignored (because of some msbuild command arg that I am not reproducing using devenv). I think the fact that dependencies are set between C++ projects is relevant too to some extent, since I've been able in other occasions to build properly setting dependencies between .NET projects and C++ projects.
In order to figure out exactly what is generating this different behavior I'd have to follow this lead: http://stackoverflow.com/questions/280559/how-to-get-cmd-line-build-command-for-vs-solution I am probably gonna do it whenever I got the time - now I am pretty busy and I got it working with a shameless hack. Do you guys agree with this? Thanks everyone for helping On Nov 12, 4:35 pm, Tom Owens <[EMAIL PROTECTED]> wrote: > Here's another thought... > I've seen similar problems using Visual Studio with Visual SourceSafe > because Visual Studio keeps it's own source control binding info (or > structure) that does not always match the structure of Visual > SourceSafe. When you open the solution with the Visual Studio IDE, it > puts all the files in the locations the solution is expecting but if > you "get" the files from VSS and build from the command line it fails > because projects aren't where the solution expects. It can be a real > bear to sort out but I can offer suggestions if it looks like that's > the issue. > > -Tom > > On Nov 12, 9:00 am, John_Idol <[EMAIL PROTECTED]> wrote: > > > @Ruben > > > I posted a question on stackoverflow about > > this:http://stackoverflow.com/questions/273836/why-build-fails-with-cruise... > > > and about how to get the build parameters when building > > manually:http://stackoverflow.com/questions/280559/how-to-get-cmd-line-build-c... > > > @Tim > > > I'll follow up with details about the msbuild output. > > > At the moment I managed to get it building with a temporary solution: > > changed from Rebuild to simple Build so that it is not wiping out the > > output dir since there's another solution which is outputing the same > > dll I am using the previous build for the import. It's a very bad > > solution but I need to get something out today > > > On Nov 12, 12:49 pm, "Ruben Willems" <[EMAIL PROTECTED]> wrote: > > > > Hi > > > > all the docs say that VS2008 uses msbuild, other versions I do not know, > > > VS2005 I think did not. > > > > But how to see what arguments get passed to msbuild, ... > > > I have no idea. > > > > with kind regards > > > Ruben Willems > > > > On Wed, Nov 12, 2008 at 1:33 PM, Giovanni Idili <[EMAIL PROTECTED]>wrote: > > > > > @Ruben > > > > Thanks for the advice. > > > > > Do you know if Visual Studio uses devenv or msbuild when I kick-off the > > > > build manually? > > > > I am trying to find out how to get that command line executed when I > > > > build > > > > manually. > > > > > On Wed, Nov 12, 2008 at 12:27 PM, Ruben Willems <[EMAIL > > > > PROTECTED]>wrote: > > > > >> Hi > > > > >> I try to use msbuild, because the error messages there are more > > > >> consistent. > > > >> Devenv seems to cache dll locations once it has found a valid one. > > > > >> That's why I suggested to delete that .suo file. > > > > >> with kind regards > > > >> Ruben Willems > > > > >> On Wed, Nov 12, 2008 at 1:20 PM, Giovanni Idili <[EMAIL PROTECTED] > > > >> > wrote: > > > > >>> @Ruben > > > >>> it is an import on a C++ project so there are not (.NET style) > > > >>> references: > > > > >>> #import "myDLLName.dll" raw_interfaces_only, raw_native_types, > > > >>> no_namespace, named_guids, auto_search > > > > >>> with the msbuild I am getting a bunch of new errors - I'll try to > > > >>> gather > > > >>> information about those but I am not to confident it's the right way > > > >>> to > > > >>> solve it. > > > > >>> I'd rather focus on getting it working with devenv. this was working > > > >>> for > > > >>> a long time then we changed build machine and it fell apart. > > > > >>> Thanks for your support > > > > >>> On Wed, Nov 12, 2008 at 12:09 PM, Ruben Willems <[EMAIL PROTECTED] > > > >>> > wrote: > > > > >>>> Hi > > > > >>>> What you can try to solve this : > > > >>>> delete the <solutionname>.suo file, and open the solution again > > > > >>>> maybe now you see the wrong references, they can be marked with an > > > >>>> exclamation mark. > > > > >>>> also when you build with msbuild, > > > >>>> the warnings should give a rather clear reason why it is failing > > > > >>>> with kind regards > > > >>>> Ruben Willems > > > > >>>> On Wed, Nov 12, 2008 at 1:04 PM, John_Idol <[EMAIL PROTECTED]>wrote: > > > > >>>>> I am trying to runthis: > > > > >>>>> devenv "MySolution.sln" /Rebuild "Release MinDependency" > > > > >>>>> It is failing with same error as cruise control so that should be > > > >>>>> why > > > >>>>> it is failing - looks like it is building the project in the wrong > > > >>>>> order (when building manually it runs just fine). > > > > >>>>> I tried with MSBUILD but it's failing on a bunch of different > > > >>>>> things ... > > > > >>>>> is there a way to find out what exact command line is being executed > > > >>>>> by Visual Studio? > > > > >>>>> On Nov 12, 10:39 am, "Ruben Willems" <[EMAIL PROTECTED]> wrote: > > > >>>>> > Hi > > > > >>>>> > you can do this by a property: > > > >>>>> > msbuild /p:configuration="Release MinDependency" > > > > >>>>> > but I doubt that another configuration will produce another result > > > >>>>> with this > > > >>>>> > problem : > > > >>>>> > dll not found > > > > >>>>> > be sure to also use the tasks /t:clean /t:build > > > > >>>>> > with kind regards > > > >>>>> > Ruben Willems > > > > >>>>> > On Wed, Nov 12, 2008 at 11:18 AM, John_Idol < > > > >>>>> [EMAIL PROTECTED]>wrote: > > > > >>>>> > > @Ruben: > > > > >>>>> > > I do I specify release mode with MSBuild? I need to build in > > > >>>>> release > > > >>>>> > > minDependency mode > > > > >>>>> > > On Nov 12, 9:31 am, "Ruben Willems" <[EMAIL PROTECTED]> > > > >>>>> wrote: > > > >>>>> > > > Hi > > > > >>>>> > > > you're building 1 VS solution right? > > > >>>>> > > > try building it with msbuild, does this work? > > > > >>>>> > > > msbuild solutionname /t:clean /t:build > > > > >>>>> > > > this cleans and rebuilds the solution > > > > >>>>> > > > with kind regards > > > >>>>> > > > Ruben Willems > > > > >>>>> > > > On Wed, Nov 12, 2008 at 10:16 AM, John_Idol < > > > >>>>> [EMAIL PROTECTED] > > > >>>>> > > >wrote: > > > > >>>>> > > > > @Ruben: > > > > >>>>> > > > > sorry I gace wrong info - the dll is sent to the output > > > >>>>> automatically > > > >>>>> > > > > in Linker->general: $(OutDir)/myDLLName.dll > > > >>>>> > > > > OutDir is the same for all the projects - I suspect the > > > >>>>> > > > > proj is > > > >>>>> not > > > >>>>> > > > > being built at all thourgh CC.NET (build order is wrong - > > > >>>>> > > > > but > > > >>>>> manually > > > >>>>> > > > > is fine, see previous answer) > > > > >>>>> > > > > On Nov 12, 8:56 am, "Ruben Willems" <[EMAIL PROTECTED]> > > > >>>>> wrote: > > > >>>>> > > > > > Hi > > > > >>>>> > > > > > Yep I meant that. > > > > >>>>> > > > > > since you're using a postscript to copy the dll, > > > >>>>> > > > > > check how the paths are definded. > > > >>>>> > > > > > suppose you use X:\\bla bla > > > > >>>>> > > > > > and X is a mapped network drive, it will not work under > > > >>>>> > > > > > the > > > >>>>> service > > > >>>>> > > > > > better is to use UNC : \\servername\sharename\... > > > > >>>>> > > > > > I use msbuild in my scripts, and this makes it easier to > > > >>>>> > > > > > spot > > > >>>>> the > > > >>>>> > > problem > > > >>>>> > > > > > just run msbuild from the command line where your > > > >>>>> > > > > > solution is > > > >>>>> in. > > > > >>>>> > > > > > with kind regards > > > >>>>> > > > > > Ruben Willems > > > > >>>>> > > > > > On Wed, Nov 12, 2008 at 9:48 AM, John_Idol < > > > >>>>> [EMAIL PROTECTED] > > > > >>>>> > > > > wrote: > > > > >>>>> > > > > > > HI Ruben - thanks for helping. > > > > >>>>> > > > > > > What do you mean with "reference path", do you mean the > > > >>>>> reference > > > >>>>> > > for > > > >>>>> > > > > > > the not found dll on the proejct that looks for it? > > > >>>>> > > > > > > It is pointing with an import to an output folder where > > > >>>>> the other > > > >>>>> > > > > > > project is supposed to copy on post build the dll. If > > > >>>>> running with > > > >>>>> > > > > > > CC.NET service dll is not in this output folder - if > > > >>>>> manually It > > > >>>>> > > is > > > >>>>> > > > > > > there (so it doesn't fail). > > > > >>>>> > > > > > > I will try to debug the problem using the console app > > > >>>>> instead of > > > >>>>> > > the > > > >>>>> > > > > > > service. > > > > >>>>> > > > > > > Any other idea? > > > > >>>>> > > > > > > On Nov 12, 7:17 am, "Ruben Willems" < > > > >>>>> [EMAIL PROTECTED]> > > > >>>>> > > wrote: > > > >>>>> > > > > > > > Hi > > > > >>>>> > > > > > > > can you check the project file manually? > > > >>>>> > > > > > > > --> open it in notepad or so, and check the reference > > > >>>>> path > > > > >>>>> > > > > > > > I've seen in many cases that VS can compile a > > > >>>>> > > > > > > > solution, > > > >>>>> but > > > >>>>> > > msbuild > > > >>>>> > > > > does > > > >>>>> > > > > > > > not. > > > >>>>> > > > > > > > and in all these cases, there was a wrong path in the > > > >>>>> project > > > >>>>> > > file. > > > > >>>>> > > > > > > > with kind regards > > > >>>>> > > > > > > > Ruben Willems > > > > >>>>> > > > > > > > On Tue, Nov 11, 2008 at 10:23 PM, John_Idol < > > > >>>>> > > > > [EMAIL PROTECTED] > > > >>>>> > > > > > > >wrote: > > > > >>>>> > > > > > > > > I have a project that builds fine If I build it > > > >>>>> manually but it > > > >>>>> > > > > fails > > > >>>>> > > > > > > > > with CC.NET. > > > > >>>>> > > > > > > > > This project is composed by a number of .NET > > > >>>>> > > > > > > > > projects > > > >>>>> and a few > > > >>>>> > > C++ > > > >>>>> > > > > > > > > dlls. > > > > >>>>> > > > > > > > > The error that shows up on CC.NET is basically > > > >>>>> > > > > > > > > related > > > >>>>> to an > > > >>>>> > > > > import > > > >>>>> > > > > > > > > that's failing because file was not found; one of > > > >>>>> > > > > > > > > the > > > >>>>> projects > > > >>>>> > > (C++ > > > >>>>> > > > > > > > > dll) tries to import a dll built by another project. > > > >>>>> Dll should > > > >>>>> > > be > > > >>>>> > > > > in > > > >>>>> > > > > > > > > the right place since there's a dependency between > > > >>>>> > > > > > > > > the > > > >>>>> projects > > > >>>>> > > - > > > >>>>> > > > > > > > > indeed when I build manually everything works fine > > > >>>>> (Note that > > > >>>>> > > when > > > >>>>> > > > > I > > > >>>>> > > > > > > > > say manually I am getting everything fresh from > > > >>>>> > > > > > > > > source > > > >>>>> code > > > >>>>> > > > > repository > > > >>>>> > > > > > > > > then invoking a Rebuild from VS2005 to simulate > > > >>>>> > > CC.NETautomation). > > > >>>>> > > > > > > > > When I run through CC.NET though the dll is not in > > > >>>>> > > > > > > > > the > > > >>>>> right > > > >>>>> > > place > > ... > > read more »
