Every other VS upgrade has been comparatively painless. I can't say I'm excited to try VS2013.
Every other VS upgrade has been comparatively painless. I can't say I'm excited to try VS2013.
Personally I am enjoying VS2012 a lot and it is really sad that there are hardly other IDEs this good.
I started using VS when I landed in a .Net shop and it made sense to use it. Totally blown away by some of the cooler features you can't find on any other IDE. Even the free VS Express (which I now use at home) is so much better than other IDE's out there.
For C++, I find VS rather lacking compared to Xcode (though that's a combination of the compiler being dumb and IntelliSense being poor).
No, it does not need to. Someone decided that it needs to pander to web monkeys instead of empowering users that have used VS for 10+ years.
Which it probably does, given the huge amount of development that is web-based these days. The market for Windows-based C# applications is shrinking by the day.
Really? How exactly does VS2012 pander to "web monkeys" at the expense of others?
There are a few exceptions to this rule (think EF Code-First), but that's a drop in the ocean.
Don't get me wrong, this type of thing drove me from the MS ecosystem a while ago now but they do move largely in the right direction, just too slowly for my tastes.
A lot of things in VS are wrappers around very well-documented CLI tools, e.g., svcutil, and I don't begrudge these tools for doing a lot of heavy lifting.
My biggest gripe are all kinds of wizards, most notably "New Project" ones. They do generate a lot of cruft I have to clean up later and pull way too many dependencies.
Maybe you are just now noticing, but MS dev tools have always had wizard clicky things. For example, see the original Visual Basics from the 90s.
My main gripe with abundance of today's "visual programming" is that we have memory-managed languages with immense expressive power and ability to write all kinds of DSLs, yet what Microsoft does is it provides crippled XML-backed designers along with half-baked frameworks and class libraries.
I actually like MFC, but it never really got past the "good for a first cut" phase, IMO. Fortunately, I've never had to deal with .NET, and besides a little MFC, most of my work is on Linux these days.
http://www.youtube.com/watch?v=hkDD03yeLnU things like this never help
>Microsoft developer tools are becoming more and more oriented towards "wizard-and-designer-clickety-clickery" type development.
Weird, I have the exact opposite impression. It seems like forever ago that VS was touting things like drag and drop design or wizardy stuff.MS have always done a good job of catering to a wide range of developer personas.
Still 100x better than digging through 100 pages of abstruse Java docs about AbstractProxyBeanDAOFactoryProxy.GenerateAbstractProxyBeanDAOFactoryAccessor though.
Closer to this: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris... than drag and drop, clickety-click.
The term "wizard" came about because of the AppWizard and ClassWizard features in Visual C++.
Clickety-clickety has been a goal of Visual Studio since before it was Visual Studio.
WiX (and MSI, for that matter) is a disaster.
With Wix/MSI, there were certain executables that I could never get it to run as part of the install process. The XML would look the same as other execute commands that worked, but I could never figure out why they didn't run.
This can "kinda" be worked around with "heat.exe" (don't get me started on naming of tools in the toolchain), but even then you'll need to explicitly specify half a dozen command-line arguments (-ag -dr -cg -srd -scom -sreg -svb6 -sfrag) to make the thing work.
Run a script to enumerate the files and populate a wix file? Zip up the different parts and have the installation process unzip them?
WiX is a thin wrapper around MSI (which sucks beyond belief) and as such it suffers full blast from all the "design" decisions of the latter, not even trying to remedy the situation.
I really could pour out a full-blown rant on MSI in general and WiX in particular, but that would be wildly offtopic and of no interest to fellow HNers.
If you hate wizards, and you hate "obscure incantations", which I'm assuming means code, then what do you like? Do you program in natural language with voice recognition?
By "obscure incantations" I mean having _three_ different syntaxes for string interpolation/variable substitution, providing _six_ command line arguments for the tool so that it does the one reasonable thing, having illogical rules in comparison operators, having to use a frickin' _bootstrapper_ to install prerequisites and not being able to chain MSIs, not being able to have a single installer for x86 and x64, not having a _simple_ way to define logic for "Back" button, yet having to write heavily nested XML to do simplest thing.
It's true that msi is different from other installer builders, but it's for a reason. And if you have a concrete project you can build while following along with the wix tutorials and book, it's not difficult, it just takes some time.
The fault of WiX is that it's too thin of a wrapper.
Considering how thoroughly MS screwed the pooch on ClickOnce, I was genuinely surprised when they completely abandoned their working installer system.
There's also no ability to publish the built installer outside of the UI- my build scripts had to build the /app.publish directory and then just copy the whole shebang to a network location for deployment. I'm not as upset about this being a separate step, but if they indeed allow you to configure and deploy the installer from within the UI why not expose an API to do it as well?
Overall I think ClickOnce is fine for internal, self-updating tools. It's worth noting, however, that I was inspired to create my workflow based on looking at what Github was doing with their windows client.
[1]: http://whazzing.com/blog/2013/04/11/automated-clickonce-buil...
Problems:
* Can't choose installation path * No offline installation * Hard (impossible?) to use with a CDN.
Here's an example of how to turn a directory of precompiled binaries into a click once package using powershell:
https://gist.github.com/jonnii/2628150
My powershell isn't _great_, so forgive any powershell oddities, but notice how much you have to massage the output of the mage tools to actually get it to do what you want.