RE: [nant-dev] FYI
Lots of great questions. Let me try to answer all of them. MSBuild namespace == Microsoft.Build.* Under Build there are a few other namespaces like Tasks.*, Framework.*, Utilities.* and Engine.* MSBuild shipping vehicle == We will be shipping as part of the .NET redistributable (aka with the CLR) in the Whidbey timeframe where Whidbey is the codename for the next release of .NET and Visual Studio, and as part of the OS in the Longhorn timeframe where Longhorn is the codename for the next release of Windows. What do I mean when I say core :) == When I said Core I meant the core of MSBuild. I was talking about some key MSBuildEngine level concepts that we feel we should patent. To elaborate a little bit on it (and I can't elaborate much), these are concepts that are novel and innovative in the build space, things you can't do today with Makefiles, Ant or NAnt. I can assure everyone that I would not dream of patenting anything that you can already do (or are publicly planning on doing) with Ant or NAnt, like having a declarative model for representing build operations (tasks), or have an XML project file, or how you bind, instantiate or configure a tasks to the project file. The concepts that are undergoing patenting are MSBuild Engine level concepts that we feel are really innovative (and most of them you haven't seen yet). You are absolutely correct when you speak about prior art, and I want to be really clear that we are not even remotely considering patenting anything where there is prior art in Ant or NAnt. In short I'd like to offer that I don't think the few patents we are filling will at all affect NAnt or Ant (and that is by design). As I've said before and I'll say again I LVE your communities, and I LOOOVE to see all this passion around the build space since I (and the rest of the MSBuild team) share that passion. I also feel I should explain a little bit how we approach patents at Microsoft and why we do it. We file patents not to deter other folks (like you) from innovating in the future, but rather as a defensive mechanism. This way when people come after us we have patents as one potential avenue of defense. Hopefully this clarifies a bit the issue. I'm sorry for being vague but as you guessed I'm not really at liberty to talk about patent things in detail, as I'm not a lawyer. I think I have said too much already :), and can feel legal breathing down my neck :). Alex Kipman ([EMAIL PROTECTED]) Program Manager Visual Studio Core Team -- This posting is provided AS IS with no warranties, and confers no rights. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Bodewig Sent: Tuesday, November 04, 2003 3:38 AM To: [EMAIL PROTECTED] Subject: Re: [nant-dev] FYI On Tue, 4 Nov 2003, Scott Hernandez [EMAIL PROTECTED] wrote: When talking about the .net core, we really need context. I thought so, thanks for the details. I'm not sure about the details of how and where microsoft is planning on inserting the build stuff. I suspect it will probably go into the System.Build.* namespaces (or somewhere around there) Looking into the RemoveDirectory sample task from the PDC set Bob has sent a link to last week: using Microsoft.Build.Framework; using Microsoft.Build.Utilities; which seems logical to me. Cheers Stefan -- http://stefanbodewig.blogger.de/ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ nant-developers mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/nant-developers
RE: [nant-dev] Bug #908317 - Project with no source files builds with an error
As I told you offline : right now, its not possible to create assemblies
containing no source files at all using the commandline compilers.
HJowever, I'm pretty sure MS will have to revise this if they intend
want to
use MSBuild as build engine in VS.NET Whidbey.
We can't just have the solution task skip the project if there are no
sources in the project, as there could, for example, be resources in the
project.
Hi Gert/Jeffrey,
Turns out we run into the same issue with MSBuild. The compilers have
very good reasons for erroring in this case, so they will not be
changing in the Whidbey timeframe. We have gotten around this problem
in our targets files. I've pasted the steps below. This ports pretty
1:1 to NAnt so you should be able to do the same to get around this
problem.
Basically we create an empty file which we then feed to the compilers.
We use our touch task to do this for us. We then clean this file.
In the beta of Whidbey if you look in our Framework.targets you'll find
the following target:
!--
Prepare the prerequisites for building.
--
Target
Name=PrepareForBuild
DependsOnTargets=$(PrepareForBuildDependsOn)
!--
Create the directories for intermediate and final build products.
--
MakeDir
Directories=$(OutDir);$(IntermediateOutputPath);
@(DocFileItem-'%(RelativeDir)')/
!--
We support building libraries even when there are no source files.
If no source file is specified in the project file, then we generate
an empty one here with an extension of
$(DefaultLanguageSourceExtension).
--
Touch
Condition='@(Compile)'==''
AlwaysCreate=true
Files=$(IntermediateOutputPath)VisualStudio.Empty
$(DefaultLanguageSourceExtension)
Output TaskParameter=TouchedFiles ItemName=Compile
Condition= '$(BuildingInsideVisualStudio)' != 'true' /
/Touch
/Target
!--
Delete the empty source file if one was created at the start of the
build.
--
Target
Name=RemoveEmptyGeneratedSource
Condition=Exists('$(IntermediateOutputPath)VisualStudio.Empty
$(DefaultLanguageSourceExtension)')
DependsOnTargets=$(RemoveEmptyGeneratedSourceDependsOn)
Delete Files=$(IntermediateOutputPath)VisualStudio.Empty
$(DefaultLanguageSourceExtension)/
/Target
Let me know if you have any other questions,
Alex Kipman ([EMAIL PROTECTED])
Program Manager
MSBuild Team
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Gert
Driesen
Sent: Friday, March 05, 2004 6:18 AM
To: Keyser, Jeffrey; [EMAIL PROTECTED]
Subject: Re: [nant-dev] Bug #908317 - Project with no source files
builds with an error
- Original Message -
From: Keyser, Jeffrey [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, March 03, 2004 9:04 PM
Subject: [nant-dev] Bug #908317 - Project with no source files builds
with
an error
Gert,
I'm answering your question in the mailing list rather than the bug
itself because I think my answer may prompt a larger discussion.
First,
let me describe our situation -
We have a VS.NET solution that was created before I started here. One
of the projects is a documentation-only project that contains only
Word
and other documents. Since VS.NET doesn't have a generic project
type,
the developers created a VB.NET library project and added the
documents
to that. They also marked that project to not be built by the
solution.
When we run the NAnt solution task on our solution, it fails on this
project.
As I told you offline : right now, its not possible to create assemblies
containing no source files at all using the commandline compilers.
HJowever, I'm pretty sure MS will have to revise this if they intend
want to
use MSBuild as build engine in VS.NET Whidbey.
We can't just have the solution task skip the project if there are no
sources in the project, as there could, for example, be resources in the
project.
To answer your question, is this really a big issue? Ultimately,
since building our solution with VS.NET doesn't fail, we want the
solution task to not fail as well. However, my proposed fix is not
the
only options, though the other option I can think of appears to be
more
painful, though cleaner in my mind.
Option #2 - change the solution task to use solution configurations
instead of project configurations. In other words, have the task look
at the solution configuration with the name in the configuration
attribute, determine which projects should be build for that
configuration and the configuration to use for each individual
project.
Since our documentation project is marked to not be built, it would
skip this one and the build would not fail.
I added support for this to cvs (and the latest nightly build).
Let me know if it works for you and if this means I can close bug report
#908317 ...
Gert
---
This SF.Net email is sponsored by: IBM
RE: [nant-dev] Bug #908317 - Project with no source files builds with an error
Forwarding to the list. I think Jomo's mail is being held for approval (since he is not a member of the alias). Thanks, A. -Original Message- From: Jomo Fisher Sent: Monday, March 08, 2004 9:30 AM To: 'Gert Driesen'; Alex Kipman; Keyser, Jeffrey; [EMAIL PROTECTED] Cc: MSBuild External Feedback Subject: RE: [nant-dev] Bug #908317 - Project with no source files builds with an error Hi Gert, You pretty much nailed it. Post-PDC we changed the first location and have also started looking in the GAC as a last resort. Here's the very most recent: (1) Any files in the project of type Content or None. (2) The semicolon delimited list of directories in the $(ReferencePath) property. This property is typically defined in the .USER file. (3) The target frameworks directory. (4) Directories found in the registry that use AssemblyFoldersEx Registration. (5) Directories found in the registry that use Visual Studio .NET 2003 AssemblyFolders Registration. (6) The file in the HintPath attribute of the reference itself. (7) The GAC. Though there are some changes brewing that might change this a little bit. I have a doc that describes our current assembly resolution process in detail, but I don't want to spam a large list. If anyone's interested, let me know and I'll mail it to you. I think you're right that we need to turn this into a KB article. Hope this helps. Jomo Fisher ([EMAIL PROTECTED]) Developer MSBuild Team This posting is provided AS IS with no warranties, and confers no rights. -Original Message- From: Gert Driesen [mailto:[EMAIL PROTECTED] Sent: Sunday, March 07, 2004 11:30 PM To: Alex Kipman; Keyser, Jeffrey; [EMAIL PROTECTED] Cc: MSBuild External Feedback Subject: Re: [nant-dev] Bug #908317 - Project with no source files builds with an error Alex, Thanks for sharing this information with us !! We'll modify our solution task accordingly ... Does the MSBuild csc task do the same or do you only feed the compiler the empty source file when building inside VS.NET ? On another note : would it be possible to add a knowledge base article on how VS.NET resolves assembly references ? Is this the correct search order ? 1. The project directory. 2. The directories specified in the ReferencePath property, which is stored in the .USER file. 3. The .NET Framework directory (see KB306149) 4. The directories specified under the following registry HKLM\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders HKCU\SOFTWARE\Microsoft\.NETFramework\AssemblyFolders HKLM\SOFTWARE\Microsoft\VisualStudio\7.0\AssemblyFolders HKCU\SOFTWARE\Microsoft\VisualStudio\7.1\AssemblyFolders HKCU\SOFTWARE\Microsoft\VisualStudio\8.0\AssemblyFolders Future versions of Visual Studio .NET will also check : HKLM\SOFTWARE\Microsoft\.NETFramework\AssemblyFoldersEx HKCU\SOFTWARE\Microsoft\.NETFramework\AssemblyFoldersEx 6. The HintPath. I, for one, have my doubts that 1 is correct ... But it would be great if this info was written down in a knowledge base article, to avoid any confusion. Gert - Original Message - From: Alex Kipman [EMAIL PROTECTED] To: Gert Driesen [EMAIL PROTECTED]; Keyser, Jeffrey [EMAIL PROTECTED]; [EMAIL PROTECTED] Cc: MSBuild External Feedback [EMAIL PROTECTED] Sent: Monday, March 08, 2004 5:46 AM Subject: RE: [nant-dev] Bug #908317 - Project with no source files builds with an error As I told you offline : right now, its not possible to create assemblies containing no source files at all using the commandline compilers. HJowever, I'm pretty sure MS will have to revise this if they intend want to use MSBuild as build engine in VS.NET Whidbey. We can't just have the solution task skip the project if there are no sources in the project, as there could, for example, be resources in the project. Hi Gert/Jeffrey, Turns out we run into the same issue with MSBuild. The compilers have very good reasons for erroring in this case, so they will not be changing in the Whidbey timeframe. We have gotten around this problem in our targets files. I've pasted the steps below. This ports pretty 1:1 to NAnt so you should be able to do the same to get around this problem. Basically we create an empty file which we then feed to the compilers. We use our touch task to do this for us. We then clean this file. In the beta of Whidbey if you look in our Framework.targets you'll find the following target: !-- Prepare the prerequisites for building. -- Target Name=PrepareForBuild DependsOnTargets=$(PrepareForBuildDependsOn) !-- Create the directories for intermediate and final build products. -- MakeDir Directories=$(OutDir);$(IntermediateOutputPath); @(DocFileItem-'%(RelativeDir)')/ !-- We support building libraries even when there are no source files. If no source file is specified in the project file, then we generate an empty one here with an extension of $(DefaultLanguageSourceExtension
