This is mostly accurate. The one nuance I'd point out, however, is that users are benefiting from Microsoft's manipulations, while they are being hurt by Google's. Doesn't make Microsoft an angel or savior, but it does make them smarter. Google is jeopardizing their customer base. I was a heavy Google user. I used Google products as much as I used Microsoft products. Recent actions they've taken, however, has drastically reduced how much I use Google. Within a year, I may be Google free. I've got to assume there's plenty of others like me, and if Google continues there's likely to be plenty more in the future.
This reminds me of the Silverlight saga in the following sense:
SL fans were busy FUDing the entire world including Microsoft instead of just pleading with Microsoft to truly open dotnet/Silverlight.
Its the same here. Instead of pleading with Microsoft to stop suing linux/android, which i have a feeling will solve this issue, WP users are busy tarnishing Google. Good luck with that.
I know you're trolling, but you have to do a better job. Comparing SL to this case is apples and bicycles. Microsoft supported the Moonlight effort, and .NET has always been an open standard. So, where are the similarities?
And what have you said?
"We know how many people use the previous versions, and their numbers were calculated the same way"
Yes, but that MS calculations were ALSO BACKED UP BY EVERYONE ELSE! The PC retail sector didn't scream bloody murder and the OS stats jived with Microsoft's license calculations. Not this time.
So everyone except Microsoft.
"Fanboi"-insult coming from you is rich.
What I said was the numbers were nuanced, and they are. They aren't as high as Microsoft wanted, but they also aren't low enough to prove failure. You keep screaming failure, but the numbers (even the ones you try to use to prove your point) don't bear that out. It's not a clear success, but it's also far (far) from a failure.
If you think I used "fanboi" to insult you, boy are you deluded . In any case, I'm not a fanbois. If I were, I'd be screaming about how great things are, which I've never done. If you think I have, it says more about your own biases than it does about mine.
Nah, the only ones lying are the pundits, fanbois and haters, such as yourself.
Please apply some analytical thought and reread what I said, because nothing you just ranted on about is relevant to anything I actually said.
VS is already getting rapid update cycles. That's what the various "update" releases are. These aren't simple service packs. You see a VS2013 product name simply because VS has always delivered with OS releases, and evidently "Blue" is being considered a big enough release to warrant the release of a new VS (more than likely there's new SDKs in Blue). None of this should be surprising to anyone here.
@cbae: Yes, and any D&D player would tell you it's two 10-sided dice.
This argument always annoys the crap out of me. It's made every single time, which is why it's pointless. We know how many people use the previous versions, and their numbers were calculated the same way, so it doesn't matter in any way how many are sold to OEMs or end users.
In any case, the numbers may not be as high as some would like, but even though they'll try, the naysayers can't really claim this proves them right. Windows 8 is certainly successful by some measure, and can't in any way be claimed to be a "total failure". That's not to say there isn't still lots of room for improvement and a very steep uphill battle for Microsoft to overcome still. As Paul Thurrott said, this is a very nuanced topic that can (and should be) read in a number of ways, and we won't know the real picture for some time to come (possibly years).
The reflection route won't always work, due to inlining. The CallerMemberNameAttribute is more reliable, but it doesn't give you the current method, but rather the calling method. Should still work for what you're trying to do, obviously, but you specifically asked about getting the current method name. I'd also point out that the CallerMemberName approach can be misused, though that's probably not something you're worried about.
The CLASSPATH in Java is a horribly broken concept, IMHO. For instance, did you know there's more than one CLASSPATH? There's the normal CLASSPATH and a "boot CLASSPATH". You hardly ever have to care about that, but when you do, confusion ensues. Not to mention all of the other nightmares involved that you can easily find by Googling on Bing. In fact, it's such a pain that tools like JWhich were created to help you figure out what's going on.
Sharing binaries seemed like a good idea in the 90s, but I think we're mostly in agreement that XCopy is the way to go today.
As a developer, I don't know why you'd care? Temporary files should be programmatically cleaned up ASAP, at worst during program termination. There are exception to that, like auto-save file type concepts, but even those exceptions leave me wondering why you'd care?
As a user, you'd care, but the answer is the same as with any temporary file: "Files stored in the folder can be removed at any time by system or by user via Disk Cleanup."