Bugs item #890721, was opened at 2004-02-04 21:35 Message generated for change (Comment added) made by drieseng You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=890721&group_id=31650
Category: Tasks Group: 0.85 >Status: Closed >Resolution: Fixed Priority: 5 Submitted By: Nick Berardi (nberardi) Assigned to: Nobody/Anonymous (nobody) Summary: <solution> copying all assemblies for framework Initial Comment: the <solution> tag is copying all assemblies from the Framework v1.1 to the bin directory of the solution that I am compiling. ---------------------------------------------------------------------- >Comment By: Gert Driesen (drieseng) Date: 2004-03-05 10:47 Message: Logged In: YES user_id=707851 Nick, This should be fixed in cvs and available in the next nightly build, which should be available later today (http://nant.sourceforge.net/nightly/builds). Don't hesitate to reopen this bug report if you still have problems. Thanks for the report ! ---------------------------------------------------------------------- Comment By: Gert Driesen (drieseng) Date: 2004-03-02 21:53 Message: Logged In: YES user_id=707851 I look into this a little further, and we currently still copy to many referenced assemblies to the output directory. By default, Visual Studio .NET does not copy assemblies that are located in the GAC to the output directory, but the <solution> task currently still copies these assemblies to the output directory. Right now, only system assemblies are not copied ... ---------------------------------------------------------------------- Comment By: Andrew Woodward (woodybx) Date: 2004-02-26 12:06 Message: Logged In: YES user_id=984789 We had a similar problem (also causes null reference expections on some no web related projects), however it would build the solution on a number of machines but not on others. The problem is related to the installation (lack of) or installation location of the default .Net Framework (V1.0) used by Nant. The machines that the build worked on had not been rebuilt since VB6 days so had all the files installed. Add the line <property name="nant.settings.currentframework" value="net- 1.1"/> at the top of the build script this forces to use .Net framework 1.1 and it should work without problem. ---------------------------------------------------------------------- Comment By: Gert Driesen (drieseng) Date: 2004-02-25 20:59 Message: Logged In: YES user_id=707851 Bug report #875674 has now been fixed and verified. Can you try the latest nightly build (http://nant.sourceforge.net/nightly/builds) and verify whether the issue you reported is now also fixed ? Thanks ! ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 13:41 Message: Logged In: YES user_id=973175 Apologies for the multiple submits there. I think the refresh button was playing havoc. : ) ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 12:50 Message: Logged In: YES user_id=973175 Without having fully invetigated the problem, I would suggest that this may be merely a special case of the problem in request - 875674. ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 12:50 Message: Logged In: YES user_id=973175 Without having fully invetigated the problem, I would suggest that this may be merely a special case of the problem in request - 875674. ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 12:48 Message: Logged In: YES user_id=973175 Without having fully invetigated the problem, I would suggest that this may be merely a special case of the problem in request - 875674. ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 12:48 Message: Logged In: YES user_id=973175 Without having fully invetigated the problem, I would suggest that this may be merely a special case of the problem in request - 875674. ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 12:37 Message: Logged In: YES user_id=973175 Without having fully invetigated the problem, I would suggest that this may be merely a special case of the problem in request - 875674. ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 12:36 Message: Logged In: YES user_id=973175 Without having fully invetigated the problem, I would suggest that this may be merely a special case of the problem in request - 875674. ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 12:35 Message: Logged In: YES user_id=973175 Without having fully invetigated the problem, I would suggest that this may be merely a special case of the problem in request - 875674. ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-12 12:17 Message: Logged In: YES user_id=973175 Hi, I have been attempting to try and narrow down the problem and have in the process come across another couple of issues. I will report them as bugs in their own right but this them in a nutshell. NAnt does not seem to be taking project level imports, (possible in VB), into consideration. When using a net-1.1 build of NAnt to build a net-1.1 solution that contains a single VB windows forms project, I am receiving the following error and the build fails. 'The SDK for the net-1.0 framework is not available or not configured.' When I use the switch /k:net-1.1. The solution builds but the executable that is produced gives me the following error when I try to run it. 'Unhandled exception at 0xf3f7d08c in WindowsApplication1.exe: 0xC0000005: Access violation reading location 0xf3f7d08c.' Note that I am using the most recent nightly build 11-Feb- 2004 12:46. The build file I am using is as follows. <?xml version="1.0" ?> <project name="SolutionTaskTest" default="test" basedir="."> <target name="test"> <solution configuration="debug" solutionfile="SolutionTaskTest.sln" /> </target> </project> ---------------------------------------------------------------------- Comment By: Gert Driesen (drieseng) Date: 2004-02-11 22:20 Message: Logged In: YES user_id=707851 Did you try this with the latest nightly build ? Can you package up a zip file containing the minimum set of files necessary to reproduce this issue, if its still not fixed in the latest nightly ? ---------------------------------------------------------------------- Comment By: Scott Munro (samunro) Date: 2004-02-11 18:33 Message: Logged In: YES user_id=973175 I am getting similar behaviour with nant-0.85-debug. I am using the following <solution> task. <solution configuration="debug" solutionfile="Munro.CodeGenerator.sln" /> and my bin folder is filled with what looks like all of the DLLs in the framework. Here is an example of one that I am not referencing in my project. System.Data.OracleClient, Version=1.0.5000.0, Culture=neutral, PublicKeyToken=b77a5c561934e089 ---------------------------------------------------------------------- Comment By: Nick Berardi (nberardi) Date: 2004-02-05 15:08 Message: Logged In: YES user_id=405152 brantcarter? I don't understand what that means because when I compile it in VS.Net I don't see this problem, where would this IsPrivate=False go? This really looks like a bug more than a issue with my project file. Because the <solution> tag should really reproduce the same .DLL's that VS.Net does. ---------------------------------------------------------------------- Comment By: Nick Berardi (nberardi) Date: 2004-02-05 15:06 Message: Logged In: YES user_id=405152 brantcarter? I don't understand what that means because when I compile it in VS.Net I don't see this problem, where would this IsPrivate=False go? This really looks like a bug more than a issue with my project file. Because the <solution> tag should really reproduce the same .DLL's that VS.Net does. ---------------------------------------------------------------------- Comment By: Brant Carter (brantcarter) Date: 2004-02-05 10:49 Message: Logged In: YES user_id=687388 This is the intended behaviour. You can change the IsPrivate attribute of your project files to change this behaviour. IsPrivate=False ---------------------------------------------------------------------- Comment By: Gert Driesen (drieseng) Date: 2004-02-04 22:42 Message: Logged In: YES user_id=707851 Nick, Can you package up a zip file containing the minimum set of files necessary to reproduce this issue ? Thanks for the report ! ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=402868&aid=890721&group_id=31650 ------------------------------------------------------- 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 _______________________________________________ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
