Impact of moving MSBuild out of the .NET redist

re: Impact of moving MSBuild out of the .NET redist

Chris Kinsman — Wed, 06 Oct 2004 02:10:00 GMT

What dependencies would this tools redist have? i.e. is this a hope for a decoupling from Whidbey...

re: Impact of moving MSBuild out of the .NET redist

Alex Kipman — Wed, 06 Oct 2004 02:15:00 GMT

Let's say for the moment this redist would still have a hard dependency on a given runtime. In our current example this redist would depend on the Whidbey .NET redist having been previously installed.

re: Impact of moving MSBuild out of the .NET redist

Slavo Furman — Wed, 06 Oct 2004 04:28:00 GMT

Hello!

My point of view is that it would be great to have ms build as part of .NET Framework redist just C# or VB.NET compiler are.

I think it would be great if one can be sure that on every machine with installed .NET Fx there will be possible to recompile sources (and do other tasks) based on ms build script.

I think having another redist to install do not (completely) break any break scenario, but it is definitely less convenient.

Are there other reasons for moving it to other redist than size of package?

As for inovations are there any plans about cooperating with Monad (MSH)?

thanks,
Slavo Furman
Microsoft ASP.NET MVP

re: Impact of moving MSBuild out of the .NET redist

Barry Dorrans — Wed, 06 Oct 2004 04:43:00 GMT

"this redist would still have a hard dependency on a given runtime"

You see, there's a killer for me. Given that msbuild is supposed to surplant/replace nAnt (leaving aside the build tasks that are missing) the fact that it needs a whitbey version of the framework and can only target that version makes it next to useless for my current project.

I don't care if it's in the framework redist or not, all I care is about having a build tool that can target v1.1 of the framework :)

re: Impact of moving MSBuild out of the .NET redist

Luc Cluitmans — Wed, 06 Oct 2004 07:14:00 GMT

I think Slavo Furman mentioned some relevant points, including the reference to MSH.

Personally, my view is this:
If msbuild is part of the standard .NET redist, it has taken a huge hurdle in getting general acceptance. If it is there, people *will* find uses for it, including ones that are outside the 'normal' developer scenarios. Not including it in the standard redist will severely hamper such applications, or make those completely non-viable. The biggest problem with this argument is of course that I cannot say what these applications would be; it is in their very definition that they don't exist yet, and won't exist until some time after .Net v2 has shipped...

Summarizing: please keep MsBuild in the standard distro.

Inconvenient but not fatal

Steve Loughran — Wed, 06 Oct 2004 07:52:00 GMT

Leaving ant out of the JDK distro didnt hurt us; it lets us evolve on a faster schedule. Given the immaturity of msbuild I'd go for separation, though you are also probalby constrained by a tight coupling of tool to IDE. Take a look how IntelliJ Idea ships with a built in Ant version but lets you choose any other one you have to hand as evidence of an alternative tactic.

As far as build/dev goes, leaving out msbuild wont hurt (much). But it does stop the tool being used as a more generic workflow/launcher/deployment language. Maybe that's good for security reasons; you dont want end users accidentally running msbuild files they get in email.

Like people say, a broader problem is that msbuild doesnt exist today in a form that is useful for anyone doing shipping products, yet its very existence threatens NAnt.

RE: Impact of moving MSBuild out of the .NET redist

dada@typicus.org (Stephane Lajoie) — Wed, 06 Oct 2004 12:49:00 GMT

You don't provide your reasoning behind this split. What in it for us? If there's no advantage for developers, of course they will complain that this makes their lives harder.

For example, if you can *significantly* reduce the size of the .Net runtime by moving the dev tools out, that would be a major win. People would be less likely to complain in that case.

It's all about tradeoffs. If you want good feedback, you have to enlighten us on the whole proposition. Merely asking if something would be a bother without showing the positives isn't very productive in my opinion.

important: we need your feedback

jeffcal's blogland — Wed, 06 Oct 2004 20:35:00 GMT

re: Impact of moving MSBuild out of the .NET redist

Robert McLaws — Wed, 06 Oct 2004 18:53:00 GMT

Here becomes the problem. If you make it a part of the Framework SDK, then does that mean I HAVE to install the SDK to install VS2005? If that is the case, then no. Keep it in the framework. The whole point of MSBuild at PDC was that ANYONE could write and compile code, cause the build Framework was right in there with everything else. That's a killer scenario, and unless there is some kind of security risk, I'd leave it in there if I were you.

Re: Impact of moving MSBuild out of the .NET redist

kprobst@gmail.com — Wed, 06 Oct 2004 21:34:00 GMT

It won't fly if you force me to install the entire SDK in order to get MSBuild. I might as well use nAnt instead.
If it's a standalone redist I can push to servers right after the framework then I don't see any problems. In fact, come to think of it I don't think it should be integrated into VS at all.

re: Impact of moving MSBuild out of the .NET redist

Junfeng Zhang — Thu, 07 Oct 2004 02:27:00 GMT

People here are most likely developers. Developers would like to keep development tool in the machine.

Unfortunately developers are only tiny amount of people in world, though important ones. Make your decision based on the major customers, and take developers' opinion into consideration.

Personally, I don't feel it unreasonable to install framework SDK to do development work.

re: Impact of moving MSBuild out of the .NET redist

William Stacey — Tue, 26 Oct 2004 19:15:00 GMT

Keep it in the Framework IMO. The less things will need to remember to install or reinstall is better. I may also want to count on it being in the framework so if at some point I want to script it for something as part of some app or rollout or something.
--
William, MVP

re: Impact of moving MSBuild out of the .NET redist

Steve Dunn — Thu, 28 Oct 2004 08:18:00 GMT

I would love to see MSBuild decoupled. I don't mind it relying on a particular version of the framework to function, but I would love to see it output binaries compiled against a chosen version of the framework

Re: Impact of moving MSBuild out of the .NET redist

mikezill@hotmail.com — Wed, 03 Nov 2004 08:22:00 GMT

To me the questions if msbuild could be used as a general purpose build system for .NET is more important than whether it is installed as part of the runtime. The adoption of msbuild will be driven by the range of use cases it is able to address. Currently the coupleing to a specific runtime version for the produced output of the build process is in my opinion the major show stopper for a wide adoption.