It is not unusual for programs to generate first-chance exceptions under ordinary circumstances. Most are handled and are not particularly interesting. I wasn’t sure how many first-chance exceptions my utility normally generated and don’t want to capture dozens of dumps looking for the exception of interest. To see what they were without capturing any dumps, I leveraged ProcDump’s exception filtering with this command line: Read More →
Representational State Transfer, or REST, is an increasingly common software architecture for creating APIs. REST, which was introduced by Roy Fielding in 2000, is not a technology in and of itself, but a set principles used to create services. RESTful APIs are almost always implemented using HTTP, but this is not a strict requirement. The following list enumerates a number of principles behind RESTful design. Read More →
Nodejitsu, founded in April 2010, is a platform as a service (PaaS) company based out of New York City. Nodejitsu provides a set of command-line tools that are used to deploy applications to their cloud. To begin using Nodejitsu, you must first register for an account at www.nodejitsu.com. Although signing up is free, deploying your application is not.
Node’s core modules do not provide an ideal logging solution. Luckily, the developer community has created a number of useful third-party logging modules. Among the best is winston, an asynchronous logging library that maintains the simplistic interface of console.log(). Below sample shows how winston is imported and used in a trivial application. Of course, you must first npm install winston in order to use the module.
Process Monitor has a hidden menu (Launch Depends…) which is visible only if the Dependency Walker (Depends.exe) utility is found. Procexp launches it with the path to the executable image of the selected process as a command-line argument. Depends.exe shows DLL dependencies. It used to ship with various Microsoft products, and it’s now distributed through www.DependencyWalker.com Read More →
An app can control the version of the .NET Framework on which it runs, but a component cannot. Components and class libraries are loaded in the context of a particular app, and therefore automatically run on the version of the .NET Framework that the app runs on.
In CLR 4
- If a project contains reference of higher CLR (.NET 3.5(console app) referencing .NET 4.0(assembly)), then project won’t compile.
- If a project contains the reference of lower CLR (.NET 4.0(console app) referencing .NET 3.5(assembly)), then the project will compile.
- The Same concept is applied for .NET versions. The Higher version can always reference, assemblies of lower version but not vice versa.
But is it different In CLR 2
- If a project contains a reference of higher CLR (.NET 2.0(console app) referencing .NET 3.5(assembly)), then the project will compile.
- If a project contains a reference of lower CLR (.NET 3.5(console app) referencing .NET 2.0(assembly)), then the project will compile.
- The Same concept is applied for .NET versions. The Higher version can always reference, assemblies of lower version and vice versa.
We can plug and unplug any electrical appliances in sockets. Even though nothing is plugged in, the wall doesn’t explode
Usually, we don’t wire electrical appliances together by attaching the cable directly to the wall. Instead, we use plugs and sockets. A socket defines a shape that the plug must match. In an analogy to software design, the socket is an interface.
If you ever stayed in cheap hotel, you will see hair drier directly attached into the wall outlet.
Now couple of problems here.
- What if your hair drier stopped working?
- What if hotel management decided to switch to new model which consumes less power?