It sounds like you just don't know Windows/VS/IIS as well as you know the other stacks which is entirely understandable since I'm guessing you don't work with them very often.
For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does. As far as IIS is concerned you can maintain all it's configuration via config files so an experienced Windows admin could have 1000's Windows servers up by lunch too. They'd probably take all day to get a Linux server up though.
> For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does.
Err, no - MSBuild, is basically a clone of Ant, except that it is meant to be generated by Visual Studio. This is completely backwards from what happens in say Java/Scala with Maven, SBT or Gradle.
The advantage of having the build process external, as happens with Maven and Maven-like environments, is that you can easily automate things by writing plugins, plus you're not tied to the IDE at all. You need to push your artifacts into a repository? There's a plugin for that. You need to sign your artifacts with a PGP key? There's a plugin for that. You need to automatically increment the version number on releases? There's a plugin for that. Etc, etc... and all of these can be used in continuos integration processes.
Plus, MSBuild doesn't handle dependency management, which is completely retarded. You've got NuGet now, but again, Microsoft had to over-engineer it, to make it IDE friendly and thus the ease of setting up your own Maven repository is gone.
And have you tried building MSBuild projects on top of Mono? Try it. It's fun ;-)
Basically only a .NET developer that never experienced other environments could claim that MSBuild/VS.NET is satisfactory, but for the rest of us, it's like trying to do software development with early-2000 tools and IMHO, that's where the entire .NET ecosystem is.
> Err, no - MSBuild, is basically a clone of Ant, except that it is meant to be generated by Visual Studio. This is completely backwards from what happens in say Java/Scala with Maven, SBT or Gradle.
MSBuild does not require Visual Studio
> The advantage of having the build process external, as happens with Maven and Maven-like environments, is that you can easily automate things by writing plugins, plus you're not tied to the IDE at all. You need to push your artifacts into a repository? There's a plugin for that. You need to sign your artifacts with a PGP key? There's a plugin for that. You need to automatically increment the version number on releases? There's a plugin for that. Etc, etc... and all of these can be used in continuos integration processes.
The equivalent of plugins for MSBuild is Tasks
> Plus, MSBuild doesn't handle dependency management, which is completely retarded. You've got NuGet now, but again, Microsoft had to over-engineer it, to make it IDE friendly and thus the ease of setting up your own Maven repository is gone.
Yes it does via NuGet, and again NuGet has no dependency on the IDE
> And have you tried building MSBuild projects on top of Mono? Try it. It's fun ;-)
Yes I have, what's your point?
> Basically only a .NET developer that never experienced other environments could claim that MSBuild/VS.NET is satisfactory, but for the rest of us, it's like trying to do software development with early-2000 tools and IMHO, that's where the entire .NET ecosystem is.
Thanks for the personal and professional attack at the end there, nice touch
That is certainly the case. But I guess my point is both ecosystems are so completely divergent that it makes sense that .NET would be an uphill battle for shops not running it elsewhere.
I remember looking into MSBuild, but I couldn't get it to work. I must have had some path set wrong or something.
For future reference you can compile VS projects from the command line if you want using MSBuild, that's all building in VS does. As far as IIS is concerned you can maintain all it's configuration via config files so an experienced Windows admin could have 1000's Windows servers up by lunch too. They'd probably take all day to get a Linux server up though.