> Currently, the msbuild task by default uses the msbuild version
> shipped with the 3.5 framework.
> If we want to use another one, we have to specify the path_to_command
> attribute.

> To simplify the use of other framework versions, I propose to use
> predefined constants that would point to the default location of well
> known frameworks.
> for 2.0sp1, its C:\WINDOWS\Microsoft.NET\Framework
> \v2.0.50727\MSBuild.exe
> for 3.5, it's C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.Exe
> and so on.

> We could end up with something like:
> t.path_to_command = '3.5'

> or even add a new attribute:
> t.framework = '3.5'

> and the task would then known which msbuild version to lookup and use.
> There would still be the possibility to set a custom location but it
> would correspond to 99,9% of the use cases.

> What do you think?

> Sounds a good idea to me.

> It would be useful to be able to set a default for the scope of all
> your tasks (most people would always use the same version) but be able
> to override it at the individual task level (some people may want to
> build against different versions from the same build script).

> The only thing I'm not sure about is how to specify the framework
> versions. Initial thought is to want to use a symbol but that is
> incompatible with what you would want to specify (1.1, 2.0, 3.5, 4.0,
> etc). There may be other behaviour related to the version of msbuild
> so rather than being a string, the framework attribute could instead
> be an object. I'm not familiar with any msbuild version other than 3.5
> so I don't know if this is the case.

> On Dec 15, 11:16 am, Andreone <nfauve...@gmail.com> wrote:

> > Currently, the msbuild task by default uses the msbuild version
> > shipped with the 3.5 framework.
> > If we want to use another one, we have to specify the path_to_command
> > attribute.

> > To simplify the use of other framework versions, I propose to use
> > predefined constants that would point to the default location of well
> > known frameworks.
> > for 2.0sp1, its C:\WINDOWS\Microsoft.NET\Framework
> > \v2.0.50727\MSBuild.exe
> > for 3.5, it's C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.Exe
> > and so on.

> > We could end up with something like:
> > t.path_to_command = '3.5'

> > or even add a new attribute:
> > t.framework = '3.5'

> > and the task would then known which msbuild version to lookup and use.
> > There would still be the possibility to set a custom location but it
> > would correspond to 99,9% of the use cases.

> > What do you think?

On Thu, Dec 17, 2009 at 1:21 PM, mendicant <mendic...@gmail.com> wrote:
> You could take a look at this:

> http://github.com/mendicantx/rubicant/blob/master/lib/dotnet/framewor...
> http://github.com/mendicantx/rubicant/blob/master/lib/dotnet/framewor...

> I know it works for 3.5 and 2.0, but obviously that's all I've used it
> for.

> It is essentially used in my MSBuild task to choose the folder for
> msbuild:
> http://github.com/mendicantx/rubicant/blob/08294cfec4f13cb3dfa45f3a80...

> It's basically a ripoff from NAnt and somewhat like how they do it.
> You just need to add a FRAMEWORK={blah} on the command line to
> override the default.

> mendicant

> On Dec 15, 5:24 am, Garry Shutler <ga...@robustsoftware.co.uk> wrote:
> > Sounds a good idea to me.

> > It would be useful to be able to set a default for the scope of all
> > your tasks (most people would always use the same version) but be able
> > to override it at the individual task level (some people may want to
> > build against different versions from the same build script).

> > The only thing I'm not sure about is how to specify the framework
> > versions. Initial thought is to want to use a symbol but that is
> > incompatible with what you would want to specify (1.1, 2.0, 3.5, 4.0,
> > etc). There may be other behaviour related to the version of msbuild
> > so rather than being a string, the framework attribute could instead
> > be an object. I'm not familiar with any msbuild version other than 3.5
> > so I don't know if this is the case.

> > On Dec 15, 11:16 am, Andreone <nfauve...@gmail.com> wrote:

> > > Currently, the msbuild task by default uses the msbuild version
> > > shipped with the 3.5 framework.
> > > If we want to use another one, we have to specify the path_to_command
> > > attribute.

> > > To simplify the use of other framework versions, I propose to use
> > > predefined constants that would point to the default location of well
> > > known frameworks.
> > > for 2.0sp1, its C:\WINDOWS\Microsoft.NET\Framework
> > > \v2.0.50727\MSBuild.exe
> > > for 3.5, it's C:\WINDOWS\Microsoft.NET\Framework\v3.5\msbuild.Exe
> > > and so on.

> > > We could end up with something like:
> > > t.path_to_command = '3.5'

> > > or even add a new attribute:
> > > t.framework = '3.5'

> > > and the task would then known which msbuild version to lookup and use.
> > > There would still be the possibility to set a custom location but it
> > > would correspond to 99,9% of the use cases.

> > > What do you think?

> --

> You received this message because you are subscribed to the Google Groups
> "albacoredev" group.
> To post to this group, send email to albacoredev@googlegroups.com.
> To unsubscribe from this group, send email to
> albacoredev+unsubscribe@googlegroups.com<albacoredev%2Bunsubscribe@googlegr oups.com>
> .
> For more options, visit this group at
> http://groups.google.com/group/albacoredev?hl=en.