Re: [nant-dev] Ongoing work on MSBuild project file formats...
Martin Aliger wrote: I dont know how much is mine work official. Hard to determine in open-source projects :-) Mostly, I was trying to find out of there is a consensus on how such a new task should work, before I spend any time on it. My company is more than willing to pay me to work on the NAnt tasks we need and submit them back to the project, but I don't want to waste their time on work that won't meet the project's goals. At the same time, if they're going to give me time to do it, I'd rather spend more time doing it right than skimp on the solution. I came up with three basic approaches, with varying degrees of complexity and benefits. I've already partly implemented #1, as apparently have a number of other people, but it seems like a sub-optimal solution. 1. Create completely separate msbuildproject and solution2005 tasks that can process generic MSBuild scripts and the new VS2005 solution format. VS2005 users could use msbuild file=whatever.csproj / or solution2005 file=whatever.sln /. 2. Create a separate msbuild task that can be used for and type of MSBuild project; add support to solution to recognize the new solution format and shunt it off to msbuild. Scripts currently using solution on a solution file would run as-is; scripts using solution without a solution file, but using a list of project files, would just not work. 3. Add a new ManagedProjectBase descendant, MSBuildProject, and support for SolutionTask to recognize and create this new type of project. Current scripts using solution either way would work as-is. Also, if we do end up with new tasks, would those properly go into nantcontrib first, even though they are closely related to the existing VSNet core tasks? Which link is dead? http://maliger.webpark.cz/binaries.zip. This should work. (try to copy/paste into yout browser if you find link broken). You'll find modified solution task and new msbuild-solution there, which knows how to compile new vs2005 projects. Also there are 2 implementations of msbuild (as a wrapper around msbuild.exe and via msbuild api). Both for direct call to msbuild. No, this wasn't the URL I found online. This one works. However, it turned out that writing an msbuild task using the MSBuild API was so straightfoward I just went ahead and did it. One very nitpicky comment I would make, is that having an msbuild-solution task is probably an inappropriate name. The solution files in VS2005 aren't MSBuild files. Reading through some of the blogs from MS's dev team indicates that the next version of VS will use true MSBuild file formats for their solution files, and the current solution format is merely a stopgap measure. It might be better to reserve the name msbuild-solution for a true msbuild-based solution file, and use something else for the current format. files, but which contained dead links. There's also an uncommitted patch in the nant CVS with a similar task. What is it? uncommitted patch? (you meant not-in-distro?) There is one patch in the nant patches database that appears to work similar to yours; submitted by B. Heath Robinson, #1246149. I only glanced at the contents of the ZIP file long enough to note that it's a completely new task, not a patch to the existing SolutionTask. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Ongoing work on MSBuild project file formats...
Short answer: look into mine sources. It solve #1, #2 and even #3. You are welcomed to make changes and polishing, of couse. Agreed #1 is trivial. But you'll (or atleast I did) soon discover that you need inter-project dependency analysis which MSBuild do _not_ solve. There are some MS blogs about it. btw: msbuild-solution could be bad name. And btw, it do not use msbuild to parse .sln files. Only .*proj files are processed with msbuild. I suggest this as temporary name, to prove its worth (in nantcontrib) and later be merged into official solution, so I didnt think about name too much. Good luck, Martin Aliger -Original Message- From: Mike Edenfield [mailto:[EMAIL PROTECTED] Sent: Friday, January 20, 2006 4:56 PM To: Martin Aliger Cc: nant-developers@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [nant-dev] Ongoing work on MSBuild project file formats... Martin Aliger wrote: I dont know how much is mine work official. Hard to determine in open-source projects :-) Mostly, I was trying to find out of there is a consensus on how such a new task should work, before I spend any time on it. My company is more than willing to pay me to work on the NAnt tasks we need and submit them back to the project, but I don't want to waste their time on work that won't meet the project's goals. At the same time, if they're going to give me time to do it, I'd rather spend more time doing it right than skimp on the solution. I came up with three basic approaches, with varying degrees of complexity and benefits. I've already partly implemented #1, as apparently have a number of other people, but it seems like a sub-optimal solution. 1. Create completely separate msbuildproject and solution2005 tasks that can process generic MSBuild scripts and the new VS2005 solution format. VS2005 users could use msbuild file=whatever.csproj / or solution2005 file=whatever.sln /. 2. Create a separate msbuild task that can be used for and type of MSBuild project; add support to solution to recognize the new solution format and shunt it off to msbuild. Scripts currently using solution on a solution file would run as-is; scripts using solution without a solution file, but using a list of project files, would just not work. 3. Add a new ManagedProjectBase descendant, MSBuildProject, and support for SolutionTask to recognize and create this new type of project. Current scripts using solution either way would work as-is. Also, if we do end up with new tasks, would those properly go into nantcontrib first, even though they are closely related to the existing VSNet core tasks? Which link is dead? http://maliger.webpark.cz/binaries.zip. This should work. (try to copy/paste into yout browser if you find link broken). You'll find modified solution task and new msbuild-solution there, which knows how to compile new vs2005 projects. Also there are 2 implementations of msbuild (as a wrapper around msbuild.exe and via msbuild api). Both for direct call to msbuild. No, this wasn't the URL I found online. This one works. However, it turned out that writing an msbuild task using the MSBuild API was so straightfoward I just went ahead and did it. One very nitpicky comment I would make, is that having an msbuild-solution task is probably an inappropriate name. The solution files in VS2005 aren't MSBuild files. Reading through some of the blogs from MS's dev team indicates that the next version of VS will use true MSBuild file formats for their solution files, and the current solution format is merely a stopgap measure. It might be better to reserve the name msbuild-solution for a true msbuild-based solution file, and use something else for the current format. files, but which contained dead links. There's also an uncommitted patch in the nant CVS with a similar task. What is it? uncommitted patch? (you meant not-in-distro?) There is one patch in the nant patches database that appears to work similar to yours; submitted by B. Heath Robinson, #1246149. I only glanced at the contents of the ZIP file long enough to note that it's a completely new task, not a patch to the existing SolutionTask. --- This SF.net email is sponsored by: Splunk Inc. Do you grep through log files for problems? Stop! Download the new AJAX search engine that makes searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642 ___ nant-developers mailing list nant-developers@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/nant-developers
[nant-dev] [ nant-Bugs-1190093 ] solution task can't compile project with Interop.Excel ref.
Bugs item #1190093, was opened at 2005-04-26 04:41
Message generated for change (Comment added) made by richardgavel
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1190093group_id=31650
Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: Tasks
Group: 0.85
Status: Closed
Resolution: Fixed
Priority: 5
Submitted By: IronEVG (ironevg)
Assigned to: Gert Driesen (drieseng)
Summary: solution task can't compile project with Interop.Excel ref.
Initial Comment:
I created an empty class library project and added
reference to COM Microsoft Excel 11.0 Object Library.
The corresponding minimal project is attached as a .zip.
Visual Studio compiles the project without any problems,
but NANT can't:
NAnt 0.85 (Build 0.85.1936.0; nightly; 20.04.2005)
Copyright (C) 2001-2005 Gerry Shaw
http://nant.sourceforge.net
Buildfile: file:///C:/Documents and
Settings/Administrator/My Documents/Visual Studio
Projects/interopTest/App.build
Target framework: Microsoft .NET Framework 1.1
Target(s) specified: build
build:
[solution] Starting solution build.
[solution] Loading projects...
[solution] Loading project 'C:\Documents and
Settings\Administrator\My Documents\Visual Studio
Projects\interopTest\ClassLibrary1\ClassLibrary1.vbproj'.
BUILD FAILED
Primary Interop
Assembly Microsoft.Office.Interop.Excel,
Version=11.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c, referenced by
project ClassLibrary1, could not be loaded.
File or assembly name Microsoft.Office.Interop.Excel,
or one of its dependencies, was not found.
Total time: 8.9 seconds.
--
Comment By: Richard Gavel (richardgavel)
Date: 2006-01-20 21:27
Message:
Logged In: YES
user_id=1178525
I actually haven't seen the issue shinghei mentioned fixed
in any version of the solution task. NAnt must find the
version of the type library mentioned in the project file,
or else it will not create the Interop assembly. Visual
Studio, on the other hand, will use the latest version equal
to or greater than the version referenced. I'm not sure if
this is with respect to only the minor version or both major
and minor (meaning if the project references 2.1 and
versions 2.2 and 3.0 are registered, I do not know is VS
would use 2.2 or 3.0). If you look into the VB6 task within
NAntContrib, you'll find that they had to deal with the same
issue.
I have had to work around this via individual xmlpoke calls
to each of the affected project files, but I would love to
see this fixed in the class.
--
Comment By: Shing (shinghei)
Date: 2006-01-19 17:46
Message:
Logged In: YES
user_id=461688
Hello,
I have a similar problem with Outlook 2003
BUILD FAILED - 0 non-fatal error(s), 1 warning(s)
Couldn't find type library Outlook
(TYPELIB\{00062FFF---C000-0046}\9.0\0\win32),
referenced by project Feedback.
Total time: 7.5 seconds.
Similar to IronEVG's experience, the project would build
fine under Visual Studio but failed when using NAnt.
This is due to the mismatch of the minor version of the
outlook type library. The project specifies 9.0 while I have
9.2. But it works just fine in the IDE.
I just tried nant-0.85-nightly-2005-12-13 but it didn't
work. Please help!
Thanks,
Shing
--
Comment By: Shing (shinghei)
Date: 2006-01-19 17:12
Message:
Logged In: YES
user_id=461688
I'd love to see this fix included in an official release or
RC...
--
Comment By: Gert Driesen (drieseng)
Date: 2005-05-29 05:39
Message:
Logged In: YES
user_id=707851
This is now fixed in cvs. I'll upload a new nightly build later
today.
Thanks for the report !
--
You can respond by visiting:
https://sourceforge.net/tracker/?func=detailatid=402868aid=1190093group_id=31650
---
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://sel.as-us.falkag.net/sel?cmd=lnkkid=103432bid=230486dat=121642
___
nant-developers mailing list
nant-developers@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/nant-developers
