4 ms·

"Ignore for a second that MonoDevelop and Visual Studio will fight over the formatting of those files, stomp on each other changes, and add garbage that’s meani

"Ignore for a second that MonoDevelop and Visual Studio will fight over the formatting of those files, stomp on each other changes, and add garbage that’s meaningless to the other. A VS- or MD-generated .csproj will be default import some target definitions called" Manual or unrecognized changes in project XML files will be preserved by (at least) Visual Studio - this is "by design" behavior. If MonoDevelop discard unrecognized constructions, this must be a bug. "Microsoft.CSharp.targets. Uh oh, what’s that? Where does that live on my system? What does it do? What package do I have to install to get that?" MSBuild. "Well, I don’t want to include that DLL in source control because checking binaries into source control is a no-no." Wrong. Test framework is either a dependency library or a tool and MUST be included under \lib or \tools folder, under the name that contains version information (say, "nunit-1.2.3"). Another way is to add library code as an external dependency and build it every time, but I think this is overkill in this particular situation. Bottom line: by keeping 3rd-party dependencies (libs or tools) local you will be getting people up to speed in no time as opposed to having to maintain detailed instruction on where to get software and how to install it. "Pretty nice! I have separate commands for msbuild and xbuild to build the .csproj files that my IDE understands, but hey, just an implementation detail, right?" Or maybe you could create an environment variable / macro that would perform all required substitution and make your build code easier to maintain. "Doing it in Ruby is a heck of a lot easier than using the ZIP task in MSBuild and I don’t have to worry about cross-platform issues." I think this pretty much summarizes the article: new set of tools + unfamiliar environment = lots of grief. About me: I maintain pretty large Windows-only project with tons of dependencies on 3rd-party .NET and COM binaries; support one-command builds into multiple release configuration, automatic versioning and hourly builds on Hudson. It took a couple of weeks in total to setup everything, but in Quick Start document I have only instructions on how to install Visual Studio and checkout latest code. Another project is an ASP.NET MVC project, where my build script in addition to building the thing, uploads binaries and content onto separate servers and does some admin stuff over SSH. I mean, know your tools, as usual.

hello_moto 15y ago
Regarding dependencies: Ruby has Gems Node has npm Java has Maven .NET has ____ I don't argue too much about checking binaries into source control but other development environments have probably smoother situation compare to .NET when it comes to 3rd-party libraries. NuGet is close but not quite there yet. Regarding Build: MSBuild is akin to that of Ant in Java. Considering that many of Java developers either have moved or are moving to use Maven, it's quite clear that .NET is lagging behind. Correct me if I'm wrong, even Clojure leiningen is very similar to Maven. There's some truth to his grief. Even if you're familiar with .NET tools, other platforms provide better experience.
- SideburnsOfDoom 15y ago
  .Net has Nuget, and that's the truth of it. If it's not good enough for you, you'll have to make a case for new features, and either implement them or wait for someone else to. What features are you lacking?
  - brugidou 15y ago
    nuget is still messy compared to maven/leiningen/rubygems, some features are lacking such as: - a system-wide repository - an easy way to integrate with .csproj builds so that building in VS will pull up necessary libs. Yes, i know there's the new auto-install feature in NuGet 1.6 but it's still not as easy as with other tools, and it requires the .nuget folder with nuget.exe in it, and i prefer people to have nuget.exe directly in their PATH anyway. - a simple way to build from the command line and in VS easily (I know this might not be feasible because VS doesn't let you do everything). For example i could just edit a bunch of dependencies in one file (not a csproj + a package.config, even if a tool does it for me it's messy) and compile it in one command or in VS. - better management of "internal" NuGet packages within a company (NuGet.Server is not so great to use although it works-ish), NuGet hasn't really been design for large-scale use unlike maven, and this is clearly showing here. It's more of a little tool to get exernal libs. In general NuGet should mavenize itself a little bit (it can't gemify itself since you'll also want to compile stuff, so imitating bundler/gem isn't enough). And i do love NuGet, i push it everywhere i can trust me :) it's one of the greatest .NET project at the moment.
    - SideburnsOfDoom 15y ago
      I agree that Nuget is a young tool, with potential. But already it has made a good difference. I hope it gets the features that we want.
- gecko 15y ago
  .NET has NuGet. You yourself mention it, then throw it out as "It's not there yet." If you're going to play that game, you have to at least explain what about NuGet is lacking. Currently, NuGet: * Is trivial to use * Can be set up on your own box for private packages * Has a pretty huge collection of packages * Avoids jamming libraries in your SCM * And pertinent to this article: works fine in Mono I know that Gems/pip/whatever have various trade-offs, but you can't summarily ditch NuGet without at least explaining why.
SideburnsOfDoom 15y ago
> Wrong. Test framework is either a dependency library or a tool and MUST be included under \lib or \tools folder Opinions differ on this, and anyone who says that their way (and their folder names) is the only right way for all circumstances is not seeing the whole picture. I've also seen a script as part of the build that updates/regenerates the nuget libraries folder. The only drawback is when there's an update and you're not on the net it will fail.
- hello_moto 15y ago
  Does NuGet support local repository a'la Maven? (setting up your own Maven remote but local within company network type of repository)
  - gecko 15y ago
    NuGet supports that. It's quite easy. http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds http://docs.nuget.org/docs/creating-packages/hosting-your-ow...
  - SideburnsOfDoom 15y ago
    Yes. http://haacked.com/archive/2010/10/21/hosting-your-own-local-and-remote-nupack-feeds.aspx http://haacked.com/archive/2010/10/21/hosting-your-own-local...

hello_moto 15y ago

Regarding dependencies: Ruby has Gems Node has npm Java has Maven .NET has ____ I don't argue too much about checking binaries into source control but other development environments have probably smoother situation compare to .NET when it comes to 3rd-party libraries. NuGet is close but not quite there yet. Regarding Build: MSBuild is akin to that of Ant in Java. Considering that many of Java developers either have moved or are moving to use Maven, it's quite clear that .NET is lagging behind. Correct me if I'm wrong, even Clojure leiningen is very similar to Maven. There's some truth to his grief. Even if you're familiar with .NET tools, other platforms provide better experience.

SideburnsOfDoom 15y ago
.Net has Nuget, and that's the truth of it. If it's not good enough for you, you'll have to make a case for new features, and either implement them or wait for someone else to. What features are you lacking?
- brugidou 15y ago
  nuget is still messy compared to maven/leiningen/rubygems, some features are lacking such as: - a system-wide repository - an easy way to integrate with .csproj builds so that building in VS will pull up necessary libs. Yes, i know there's the new auto-install feature in NuGet 1.6 but it's still not as easy as with other tools, and it requires the .nuget folder with nuget.exe in it, and i prefer people to have nuget.exe directly in their PATH anyway. - a simple way to build from the command line and in VS easily (I know this might not be feasible because VS doesn't let you do everything). For example i could just edit a bunch of dependencies in one file (not a csproj + a package.config, even if a tool does it for me it's messy) and compile it in one command or in VS. - better management of "internal" NuGet packages within a company (NuGet.Server is not so great to use although it works-ish), NuGet hasn't really been design for large-scale use unlike maven, and this is clearly showing here. It's more of a little tool to get exernal libs. In general NuGet should mavenize itself a little bit (it can't gemify itself since you'll also want to compile stuff, so imitating bundler/gem isn't enough). And i do love NuGet, i push it everywhere i can trust me :) it's one of the greatest .NET project at the moment.
  - SideburnsOfDoom 15y ago
    I agree that Nuget is a young tool, with potential. But already it has made a good difference. I hope it gets the features that we want.
gecko 15y ago
.NET has NuGet. You yourself mention it, then throw it out as "It's not there yet." If you're going to play that game, you have to at least explain what about NuGet is lacking. Currently, NuGet: * Is trivial to use * Can be set up on your own box for private packages * Has a pretty huge collection of packages * Avoids jamming libraries in your SCM * And pertinent to this article: works fine in Mono I know that Gems/pip/whatever have various trade-offs, but you can't summarily ditch NuGet without at least explaining why.

SideburnsOfDoom 15y ago

> Wrong. Test framework is either a dependency library or a tool and MUST be included under \lib or \tools folder Opinions differ on this, and anyone who says that their way (and their folder names) is the only right way for all circumstances is not seeing the whole picture. I've also seen a script as part of the build that updates/regenerates the nuget libraries folder. The only drawback is when there's an update and you're not on the net it will fail.

hello_moto 15y ago
Does NuGet support local repository a'la Maven? (setting up your own Maven remote but local within company network type of repository)
- gecko 15y ago
  NuGet supports that. It's quite easy. http://docs.nuget.org/docs/creating-packages/hosting-your-own-nuget-feeds http://docs.nuget.org/docs/creating-packages/hosting-your-ow...
- SideburnsOfDoom 15y ago
  Yes. http://haacked.com/archive/2010/10/21/hosting-your-own-local-and-remote-nupack-feeds.aspx http://haacked.com/archive/2010/10/21/hosting-your-own-local...