231–235 of 235 posts
Earlier quoted context omitted.
But with a 'using' you can't catch an exception. So in production I end up using ( ;-) ) try catch finally.
> with a 'using' you can't catch an exception [Citation needed]
Then what's the point of having a 'using + catch' instead of a 'try catch finally' ?
Earlier quoted context omitted.
ReSharper is an infamous hog. It makes VS freeze up, devours memory, and devours extra CPU cycles with background threads. It is at least a really useful add-on...
This. We just blew away 50 licenses because on our project it's a hindrance even on our E5 Xeons with 24Gb RAM and SAS+SSD disks.
Earlier quoted context omitted.
Most every command that can be done with a gui can be done via command line, mostly powershell; which you can use remotely. In fact I would be hard pressed to find any administration routine that cannot be done through command line and is not documented.
The thing that I could use most is a way to automate setting up a reverse-proxy on a given path. I've figured out the steps to make it happen in the GUI. But that is tedious and error prone. Where would you suggest I go to find the best way to handle this?
Earlier quoted context omitted.
ReSharper is an infamous hog. It makes VS freeze up, devours memory, and devours extra CPU cycles with background threads. It is at least a really useful add-on...
This. We just blew away 50 licenses because on our project it's a hindrance even on our E5 Xeons with 24Gb RAM and SAS+SSD disks.
Earlier quoted context omitted.
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 admi…
> 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 e…
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