The rule of thumb I use is pretty simple. If i'm designing a class that depends on some other class, and there is a logical reason for that class to change either at runtime or in testing then I use dependency injection. I also use DI when it makes sense to control something at runtime, such as a configuration entry, connection string, etc... or anything I might otherwise use a factory for. Your example above for INowResolver seems kind of silly at first glance, but in reality, it's a great example of a DI resource. The problem with DateTime.Now is that you cannot alter this in testing, it always uses "Now" even when you might want to use a different time for "Now" (think when you want to test what happens in 2037 when the Y2037 bug hits, you can now substitute INowResolver with a different date/time for "now" to test what will happen in the future). Yes, you could write conditional code in your method to deal with this, but now you have test code in your methods, rather than in your test cases, which makes them messier and more difficult to maintain. There are also "Moles" or Proxy stubs that can replace the runtime behavior of methods like DateTime.Now, but not everyone uses those. Your problem here is that you're not truly understanding the purpose of Dependency Injection, and as such you have a hard time understanding why it's used so much. You probably see it as a simple service locator or abstract factory service... injecting stuff so you don't have to bother typing "new". While it's true that you can use it for that, it really opens up a whole new array of possibilities when you "drink the Kool-Aid". As for your Utility functions... in general, no.. you don't need to use DI for utility functions if there is no configuration or other dependencies involved. Particularly if they are pure static methods with no state.

-- Where are we going? And why am I in this handbasket?

How is the key any different from the password then? Key + Password = Password... they're the same thing. Just have the user enter both in the password field, and use standard hashing.

-- Where are we going? And why am I in this handbasket?

This is a variation of a fairly common way of abstracting your data layer in Unit of Work and Repository patterns. First, let me say there is nothing "enterprise" about this. It's used in both small, medium and large applications. So anyone that told you this was about enterprise development was feeding you a line. Second, this particular implementation is a bit heavy on the abstractions.. and could probably be slimed down, but there is basically nothing wrong with it, other than having to maintain all those extra abstractions. (also, depending on who you talk to, some people feel that generic repositories are a bad idea, and an anti-pattern. I'm one of them, but It is a controversial subject). Third, if you're using Entity Framework as your underlying data model, these abstractions are probably just extra noise since EF already provides these abstractions in the form of your DbContext and DbSet, which are already Unit of Work and Generic Repsitory respectively. You can add interfaces to these to make them more Dependency Injection friendly fairly easily, and as of EF6 they provide mockability so neither DI or Unit testing are good reasons to add the extra abstraction layers anymore. However, some people like the comfort of knowledge that they may want to replace their data layer some day and adding these abstractions (in theory) makes that easier (although in practice it's usually not so simple as these are leaky abstractions which tend to leak into your application layers anyways). However, having said all that.. if you already have this infrastructure, I wouldn't go ripping it out unless you find it to be too burdensome to maintain. Now, on to the interfaces... Yes, you absolutely should be using interfaces. For reasons of Unit testing and Dependency Injection, as well interface segregation principle. Using an interface helps decouple your implementation from the contract you use to access it. It's important to realize that "enterprise architecture" is a lot more than just adding an abstracted data layer. It's creating standards that your enterprise follows, and architecting your suite of applications to work together. It's having an infrastructure or technologies, like Service Busses, or Message Queues and planning redundancy, durability, and failability. In short, it's about seeing the forest and not the trees.

-- Where are we going? And why am I in this handbasket?

While it's true that interfaces are useful for these purposes, that's not why they exist or why they are mainly used. Interface Segregation Principle is one of the Five principles of SOLID design, and stands on its own beyond its use in testing or DI. Interfaces are used to decouple implementation from contract and are important in many other patterns and practices. Do not fall into the trap of thinking they are only useful for testing or DI, and they don't need to be used otherwise.

-- Where are we going? And why am I in this handbasket?

Your global.asax file won't update because it hasn't changed. This file only has a small amount of metatdata in it to point to the DLL. If you right click on the global.asax in your solution explorer, choose "view markup" and you will see only a single line of code that looks like this:

<%@ Application Codebehind="Global.asax.cs" Inherits="WebApplication.Application" Language="C#" %>

Since this file doesn't change, it won't be updated when you deploy. As such, this isn't the cause of your problems. More than likely, the cause is something else, but since you haven't included more details about your problem we can't really help more.

-- Where are we going? And why am I in this handbasket?

The reason you are not getting any answers is that you are not asking your question in a way that makes it easy to understand. You are also not even asking any real question at all. You are simply stating a bunch of facts... And then saying "It's slow, help me". You will get much better results if you rewrite your question with very specific questions, and provide only the code necessary to recreate the problem. Ask questions that can be answered explicitly, not open ended questions. We don't know what to do with "It's slow, please help me".

-- Where are we going? And why am I in this handbasket?

MVC4 is actually quite old now. MVC 5.2.2 is the most recent version, and MVC6 is in development (for release later this year). You can download the free Community Edition of Visual Studio 2013 for personal use to learn MVC 5.x, or you can download the Visual Studio 2015 CTP if you want to get a head start on MVC6.

-- Where are we going? And why am I in this handbasket?

<dialog> is just an element you use in your views. There is nothing in MVC that prevents you from using it in your markup, but there is nothing that generates it either. You just wrap whatever code you want in a dialog element, then use a technology like jQueryUI-dialog to utilize it. I've never heard of divc, and can find no reference to it.. so not sure what you're referring to.

-- Where are we going? And why am I in this handbasket?

Ok, but the first is the compiler tools, not the IDE. The second is the change to support multiple monitors. You lose some while gaining the other.

-- Where are we going? And why am I in this handbasket?

Wow, talk about an irrational argument. First, there is no contract between the users at the pumps and BP. Further, consumers are protected by a host of consumer protection laws which prevent such responsibility. However, there is an argument to be made that those that buy a companies products are also responsible for that companies actions, particularly if they are aware of said actions. This is a moral argument though, not a legal one. BP had legal contracts in place with TransOcean and Haliburton. Those companies were doing the work at the behest of BP. It's like saying the US isn't responsible for the people killed in Iraq by Blackwater personel because they're a private company. Is blackwater (and Haliburton and Transocean) responsible for it's actions? Sure. But so is the employer, BP or the US Government. And ultimately the employer holds the majority of the blame, especially since they did not oversee the work and validate it's safety before putting it into production. Yes, if Haliburton started hacking pregnant women into bloody chunks while operating under a BP contract, BP is responsible for that. Haliburton may also be, and the actual employees doing it as well because there are specific laws (Murder) against the action. However, there is no law broken for shoddy work. Only the effects of the shoddy work, which the parent company is responsible for. To put it a little clearer. Suppose you hired a 10 year old kid to mow your lawn. And, while mowing the lawn, the kid mowed over your neighbors dog, flower garden, did damage to their car and house. Can you say "Well, it's not my responsibility, sue the 10 year old kid"? No, you can't. As his employer, you are responsible for his actions. That's the way employment law works, that's the way contractual law works.

-- Where are we going? And why am I in this handbasket?

What functionality is reduced in 2010?

-- Where are we going? And why am I in this handbasket?

Where to start.. where to start. there's so much wrong with this code that it seems clear you haven't even a basic idea of how execution scopes work, or what happens when you leave a block of code. I'm not criticizing you, but you're lacking some fundamental knowledge here. First, in your "server" you click a button to start.. ok, but all your code is running within that button click event.. which will lock up your UI on the server until processing is finished. This is probably not what you have in mind for a long running connection. You will most likely have to create a worker thread to handle this code, which I won't go into detail about much here.. but something for you to research into. Next, you create new NetworkStream and StreamReader/Writer objects within your while loop. This is highly wasteful, and will likely cause a lot of problems. I believe that when the NetworkStream object is destroyed at the end of your while loop, it will close the socket that it's attached to unless you specify false for socket ownership in the constructor. So your first step would be to move those three lines to outside of your while loop (but inside the if statement), that will keep them around while you process things. Next, you need a way to tell when the socket has been closed. Certainly, your exception handler will do that, but it's not the "correct" way. ReadLine() returns null when the socket is closed. So you should change your code to exit the loop when ReadLine() returns null. Now on to the client. First, you will probably want to create a "connect" button and a "disconnect" button (or you can get fancy and use the same button for both). This will create the TcpClient connnection and leave it open. The close will close the connection. Then you button click will do nothing but send the text in your textbox. You may want to create a second textbox to display the output that comes back instead of using a MessageBox.

-- Where are we going? And why am I in this handbasket?

It's probably not just you, but it's certainly not me. It seems some people just hate change. Whenever anything changes, all they can do is complain about it. They hate the ribbon, they hate the new Windows 7 toolbar. They hate the new XP Start Menu. These people configure their systems to look as much like Windows 2000 (or even 9x) as possible. If you work in technology, you have got to be prepared for change. That's what it does. All the time. You can't expect that things will stay the same, and more importantly, you have to learn to embrace it. Every change may not be to our liking, but you're going to be flattened by the steamroller of time if you don't learn to roll with it.

-- Where are we going? And why am I in this handbasket?

Uhh.. so what? It's debug. They've added more debug code most likely. And, as you say, you can't strip debug info.. Why do you want to build a debug build but not have any debugging info? Seems odd to me. Now, what are the release build sizes? THAT would be important.

-- Where are we going? And why am I in this handbasket?

No, BP is entirely to blame. There may be others that are at fault, but seeing as it's BP's operation, and they're paying the bills, they are the one responsible. For everything. This isn't the first time either, BP was responsible for a terrible oil spill in Alaska in 2006, which they also tried to hide, then understated, then pretended to be doing all it could... http://www.msnbc.msn.com/id/11958576/[^] BP hired those companies. Certainly, TransOcean and Haliburton are US companies, but they were just contractors. BP has the ultimate say over the work being done, and the responsibility to make sure it's done safely and correctly. Many of us work as contractors for large corporations. We are not "responsible" for the work we do. If our work kills someone, or causes aircraft to fall out of the sky, we will not be held responsible for it. The companies that hired us are. Granted, those companies could well try to sue us as well, but ultimately, they are responsible for whatever it is they sell.

-- Where are we going? And why am I in this handbasket?

I'm not sure you understand the meaning of "double standard", either that or you don't understand the meaning of "irony" because your post is a brilliant example of it. You're complaining that the president of the US didn't run out to Bhopal and the US citizens weren't up in arms, when the British Prime Minister hasn't run out and few british citizens seem to be up in arms. Why aren't you complaining about them? The fact is, it's a US territory, and the US is responsible for regulating companies doing business in their territory. While the US could be concerned about US companies operating abroad, there is nothing they can legally do unless those companies are violating international law. It's the responsibility of the government in which country the company operates to police the company, not the US. In fact, I would imagine that India would have been quite cross with the US if they came over and forced Union Carbide to shut their doors and fire all their employees. So, perhaps you should think about your argument before you make it.

-- Where are we going? And why am I in this handbasket?

Sorry, I have several versions of those reference books myself. Actually, i just got done throwing out about 3/4 of my computer books (well, recycled). It was time. I haven't coded MFC in years either, and as long as i'm doing vertical apps, i have little reason to use it. There are certain classes of apps that I would still write in C++ with MFC though, particularly if I were working on a commercial quality app.

-- Where are we going? And why am I in this handbasket?

MFC is not that difficult, it's actually pretty straight forward. More often than not those that have trouble with it are making it more complicated than it is. If you want to do MFC development, there is one and only one real book you need to read (in addition to the MSDN library). That book is MFC Internals by Scot Wingo and George Shepherd. It completly cuts through the fluff and explains how MFC works, and gives you the knowledge you need to understand every basic part of it quite easily. It's an old book, and doesn't cover anything since VS6, but it's still just as relevant. After reading that book, i largely abandonded all the wizards and hand wrote everything. It was a breeze. And MFC was not abandoned.. Microsoft made a number of enhancements to it in each new version of Visual Studio, but the thing that has always been lacking is GUI support. Even VS6 provides more GUI support than any .NET version of Visual Studio, but for those who have read "The" book, it doesn't really matter.

-- Where are we going? And why am I in this handbasket?

Where the heck did you find a Pentium motherboard that supports 128MB of memory? All the ones I knew of had 64MB limits back in the day.

-- Where are we going? And why am I in this handbasket?

Well, Microsoft has been working hard at reducing the number of conditions where a reboot is required on Windows Server, but it's still not 100% free of them. Security patches, especially service packs will typically require a reboot. This can be mitigated by using load balancing, though (which is a good idea if you are concerned about uptime because even if your OS can guarantee no downtime (none can), hardware failure happens.) Having said that, Windows Server is very stable, however it depends largely on the people who are running it. Many people seem to believe that the solution to everything is to reboot first and ask questions later. The new Windows Server 2008 looks very promising. it hasn't been fully vetted by a large number of users yet, but they've taken many steps that should improve uptime, reduce attack surfaces, and make it more secure. Something to keep in mind is that IIS6 had only 3 security vulnerabilities since it was released in 2003, and none of them were critical. Compared to Apache, that's extremely good. Also, consider that some of the largest websites in the world run Windows Server. Godaddy, Ebay, Facebook, and of course Microsoft, etc... Could it run non-stop for 1 year? Yes, most likely, but that would mean not applying any patches that require a reboot. And yes, used as an IIS server or SQL Server. Yes, it can run as a firewall, using third party products, WIndows Routing and Remote Access, or ISA Server (though as I understand it, ISA Server is not currently compatible with 2008, though there is an update planned). There are also tons of tools for remote administration, depending on your definition of "remote". If you mean through a VPN tunnel, then you can use the remote admin tools that ship with it, or you can download from Microsoft. There are also a lot of third party tools like Dameware. Chances are, you being the lone man out will have a hard time getting heard. For every reason you give, 20 other guys will FUD it.

-- Where are we going? And why am I in this handbasket?