Interesting article about heap, stack and Garbage Collector can be found here: http://www.c-sharpcorner.com/UploadFile/rmcochran/csharp_memory01122006130034PM/csharp_memory.aspx
Other source: Top 20 .NET Garbage Collection (GC) Articles
POST-Redirect-GET Pattern
August 18, 2009 at 3:33 pm (Technical Corner)
HTTP supports several methods that define the nature of the current request. The two most important ones are GET and POST. GET is the primary method to get content (so called entities) from the server such as HTML pages, images, CSS style sheets etc. The POST method on the other hand is meant to transport entities to the server, for example login credentials or a blog comment. On the server side a POST request often results in an update of certain data (databases, session state).
Both GET and POST can return an entity as a response. For GET this is obvious – it’s what the method exists for in the first place. For POST it might sound reasonable in the first place as well, but it brings a pile of problems.
A simple scenario
Imagine you fill in a sign-up form of some web based e-mail service and POST it to the server using a submit button. The server processes the new account and updates its database. Maybe it even logs you in directly. In response of the POST request the server directly shows you a view of your inbox. Here’s a diagram of what happens between browser and server:
- The browser POSTs form data to an URL called signup.aspx
- The server processes the request
- The server responds with a status code of 200 (OK) and sends back a view of the new users inbox rendered as HTML
You leave the computer to have a coffee and when you come back 5 minutes later you refresh the page (using CTRL+R or F5 or whatever shortcut your browser uses) to see whether you already have new messages. You are a bit puzzled why this (or a similar) message box appears:
You click on OK and are even more confused as the page that appears says “This user name is already taken” instead of showing your inbox .
What has happened? Remember that the page you saw was the response of a POST request (submitting the sign up form). When you refreshed the page and confirmed to “resend the data” you actually repeated the POST request with the same form data. The server processed the “new” account and found that the user name is already in use (by yourself!), therefore it showed an error. “But wait”, you say, “I just wanted the server to refresh the view of my inbox, what have I done wrong? ” The answer is: nothing! The problem is that the application abused the POST response to transport an entity back to the client that should have been accessed with a GET request in the first place.
POST related issues
Here are some of the problems that occur if you abuse POST requests to return entities:
1. Refreshing the page results in a re-transmission of the POST data
This is what I described above. Hitting “refresh page” for a reponse based on a POST request will re-issue the POST request. Instead of refreshing what you see this will repeat what you did to reach the current page. This is not “refresh page” anymore, it becomes “repeat last action” – which is most likely not what the user wants. If you see a summary page after you have submitted an order in an online store, you don’t want F5 to drop another order, do you?
2. POST responses are hard to bookmark
Bookmarks (or favourites etc.) normally only remember the URL of the bookmarked page (along with some user supplied meta data). Because a POST request transports data in the request body instead as query parameters in the URL like GET does, bookmarking the result of a POST will not work in most cases.
3. POST responses pollute the browser history
If the browser keeps the result of a POST request in it’s history, going back to that history entry will normally result in POST data to be retransmitted. This again causes the same issues as mentioned in point 1.
POST-Redirect-GET
“But I need POSTs to send forms to the server – how can I avoid the problems mentioned above?” you might say. Here’s where the POST-Redirect-GET (PRG hereafter) pattern enters the stage.
Instead of sending entity content with the POST response after we processed the request, we return the URL of a new location which the browser should visit afterwards. Normally this new location shows the result of the POST or an updated view of some domain model.
This can be achieved by not returning a result code of 200 (success) but instead returning a status code that indicates a new location for the result, for example 303 (“See other”) or 302(“Found”/”Moved temporarily”), the latter of which is used most often nowadays. Together with the 30x result code a Location header is sent which contains the URL of the page to which the request is redirected. Only the headers are sent, no body is included.
If the browser sees the 30x status code, it will look for the Location header and issue a GET request to the URL mentioned there. Finally the user will see the body of that GET request in the browser.
The browser-server communication would look like this:
- The browser POSTs to signup.aspx
- The server updates some state etc.
- The response is 302 redirect with a Location header value of inbox.aspx
- The browser realizes that the response is redirected and issues a GET to inbox.aspx
- The server returns 200 together with the content of the resource.
What do we gain?
- The page can be safely refreshed. Refreshing will cause another GET to inbox.aspx which won’t cause any updates on the server
- The result page can be easily bookmarked. Because the current resource is defined by the URL a bookmark to this URL is likely to be valid.
- The browser history stays clean. Responses that have a redirect status code (such as 302) will not be put into the browser cache by most browsers. Only the location to which the response is redirecting is. Therefore signup.aspx won’t be added to the history and we can safely go back and forth through the history without having to resubmit any POST data
The problem with ASP.NET WebForms
Now that you know about POST-Redirect-GET you are of course eager to use it (at least I hope I could convince you). But as an ASP.NET WebForms developer you will soon run into problems: ASP.NET WebForms is fundamentally based on POSTs to the server. In essence, all ASP.NET web pages are wrapped in one huge
element with “method” set to “POST”. Whenever you click a button, you essentially POST all form fields to the server. Of course you can redirect from a Button.Click handler. If you do so, you’re applying PRG. At the same time you’re working quite against the WebForms philosophy, especially the ViewState (which will get lost as soon as you redirect), which will force you to rethink a lot of your application logic. And if you don’t rely on all this postback behaviour inherent to ASP.NET WebForms you might as well ask why you’re using WebForms in the first place.
This makes clear why a lot of developers (including me) think that WebForms are inherently “broken” (viewstate, ubiquitous postbacks and the hard-to-mock HttpContext are just a few reasons). If you share these concerns but like .NET just as I do, you might want to look at alternate .NET based web frameworks such as Castle MonoRail or ASP.NET MVC.
See entire article: http://blog.andreloker.de/post/2008/06/Post-Redirect-Get.aspx
.NET Remoting
June 3, 2009 at 10:58 am (Technical Corner)
Tags: .NET Remoting
Remoting is a system for Microsoft .NET platform that enables interprocess communication in a homogenous environment. With the help of remoting, we can communicate between two processes running on different machines (or different application domains) in a network (but having the same OS). Because remoting uses binary serialization, it is much faster than using web services. However, we cannot use remoting in a heterogeneous environment (say, where an ASP.NET web application is talking to a J2EE application) using a .NET specific API, as other systems, such as J2EE, cannot understand it. Also, the use of remoting when we want to talk to processes outside of the LAN (say, when communicating using WAN or Internet) can be troublesome, as it cannot bypass a firewall until specific access is given to the service. Using web services is preferred in such cases.
source: ASP.NET 3.5 Application Architechture Design
DLL versus EXE
May 26, 2009 at 10:19 am (Technical Corner)
Tags: DLL vs EXE
The most important difference is that an EXE is a program that can be run by the user or by another program. When you run an EXE it loads it into memory and then loads any DLLs it uses and calls the EXE’s main procedure. Although EXEs and DLLs share the same format, the OS will not allow a DLL to be executed.
A DLL is not meant to be run. It is a library. It is a collection of procedures and data that can be used by other code modules (by EXEs and other DLLs).
Is the ordinary EXE same as static linked library ?
Not at all. An EXE is not a library in any sense. A library is a collect of code ot data that can be used by other code. An EXE cannot be used in this way. A DLL can, thus a DLL is a library, but not a static linked library.
A DLL is basically a repository for shared code. The benefit of using DLL’s is that if 8 programs (EXE’s) use the same function, with a DLL, the binary code is only loaded into memory once and all 8 programs attach to the DLL, so it reduces the memory footprint some. As an example, the common dialogs (File Open, File Save, etc.) reside in a DLL. If these were statically linked, each program would have its own copy of all of the common dialogs, and would increase its memory footprint accordingly.
An EXE is loading into memory when somone wants to run it. That could be the user, or another program. A DLL is loaded when an EXE or DLL is loaded that uses it (EXE when loaded with LoadLibrary). When the DLL is loaded it does not “run” like and EXE runs. It sort of just “sits there” and waits for other code modules to use the procedures and data it provides.
so where is the advantage ?
There is no advantage, they serve different purposes. The EXE is a program It is the ultimate goal of programming. it is something useful to the user. A DLL is a library that can be used to make useful EXEs but by themselves they are useless. In the end an EXE is necessary to make the the DLL do userful things.
(source: http://www.experts-exchange.com/Programming/System/Windows__Programming/Q_10129393.html )
Static Typing vs Dynamic Typing
May 26, 2009 at 9:29 am (Technical Corner)
Tags: Dynamic Typing, Static Typing
Static Typing
Static typed programming languages are those in which variables need not be defined before they’re used. This implies that static typing has to do with the explicit declaration (or initialization) of variables before they’re employed. Java is an example of a static typed language; C and C++ are also static typed languages. Note that in C (and C++ also), variables can be cast into other types, but they don’t get converted; you just read them assuming they are another type.
Static typing does not imply that you have to declare all the variables first, before you use them; variables maybe be initialized anywhere, but developers have to do so before they use those variables anywhere. Consider the following example:
/* C code */
static int num, sum; // explicit declaration
num = 5; // now use the variables
sum = 10;
sum = sum + num;
The above code fragment is an example of how variable declaration in static typed languages generally appears. Note that in the above code, static has nothing to do with static typing; it has been used along with int only to initialize num and sum to zero.
Dynamic Typing
Dynamic typed programming languages are those languages in which variables must necessarily be defined before they are used. This implies that dynamic typed languages do not require the explicit declaration of the variables before they’re used. Python is an example of a dynamic typed programming language, and so is PHP. Consider the following example:
/* Python code */
num = 10 // directly using the variable
In the above code fragment, we have directly assigned the variable num the value 10 before initializing it. This is characteristic to dynamic typed programming languages.
Another Analogy
A lot of people define static typing and dynamic typing with respect to the point at which the variable types are checked. Using this analogy, static typed languages are those in which type checking is done at compile-time, whereas dynamic typed languages are those in which type checking is done at run-time.
This analogy leads to the analogy we used above to define static and dynamic typing. I believe it is simpler to understand static and dynamic typing in terms of the need for the explicit declaration of variables, rather than as compile-time and run-time type checking.
Strong-typing vs weak-typing
May 26, 2009 at 9:21 am (Technical Corner)
Tags: strong types, weak types
What is a “type”, anyway?
A type is metadata about a chunk of memory that classifies the kind of data stored there. This classification usually implicitly specifies what kinds of operations may be performed on the data.
Common types include primitive types (strings and numbers), container types (lists/arrays and dictionaries/hashes), and user-defined types (classes). In Python, everything is an object, and every object has a type. In other words, functions, modules, and stack frames are also types.
Weak typing is where a language allows you to treat blocks of memory defined as one type as another (casting). Languages like C and C++, although statically typed, are weakly typed.
Languages like Perl and PHP are weakly typed because you can do things like adding numbers to strings and the language will do an implicit coercion for you.
Languages like Java, C# and Python are strongly typed - there is no way you can add a number to a string without doing an explicit conversion.
In addition, there are many large systems that have been created with dynamic type systems. Catching type errors (typos) at compile time only catches a very small proportion of errors and a strong testing strategy produces much more reliable systems irrespective of the type system in use. (source: http://wiki.answers.com/Q/What_is_strong-typing_versus_weak-typing)
Strong typing prevents mixing operations between mismatched types. In order to mix types, you must use an explicit conversion. Conversely, weak typing means that you can mix types without an explicit conversion (source: http://www.artima.com/weblogs/viewpost.jsp?thread=7590)
.NET Framework
May 18, 2009 at 11:36 am (Technical Corner)
Tags: .NET Framework
The Microsoft .NET Framework is a software framework that can be installed on computers running Microsoft Windows operating systems. It includes a large library of coded solutions to prevent common programming problems and a virtual machine that manages the execution of programs written specifically for the framework. The .NET Framework is a key Microsoft offering and is intended to be used by most new applications created for the Windows platform.
The framework’s Base Class Library provides a large range of features including user interface, data and data access, database connectivity, cryptography, web application development, numeric algorithms, and network communications. The class library is used by programmers, who combine it with their own code to produce applications.
Programs written for the .NET Framework execute in a software environment that manages the program’s runtime requirements. Also part of the .NET Framework, this runtime environment is known as the Common Language Runtime (CLR). The CLR provides the appearance of an application virtual machine so that programmers need not consider the capabilities of the specific CPU that will execute the program. The CLR also provides other important services such as security, memory management, and exception handling. The class library and the CLR together constitute the .NET Framework.
(source: Wikipedia )
Support Certificates In Applications With The .NET Framework 2.0
April 27, 2009 at 4:35 pm (Technical Corner)
Tags: .NET Security
Certificates are used in many places across the Microsoft® .NET Framework, from secure communication to code signing to security policies. The .NET Framework 2.0 introduced revamped support for certificates and it added a completely new namespace for standards-compliant cryptographic operations with certificates. In this article, I will discuss the background for certificates and the Windows® Certificate Store. I’ll also show you how to work with the certificate APIs and how they are used by the Framework to implement security features.
A “certificate” is really an ASN.1 (Abstract Syntax Notation One) encoded file that contains a public key and additional information about that key and its owner. In addition, a certificate has a validity period and is signed with another key (the so-called issuer) which is used to provide an authenticity guarantee of those attributes and, most importantly, the public key itself. You can think of ASN.1 as a sort of binary XML. Like XML, it also has encoding rules, strong types, and tags; however, these are binary values that often don’t correspond to any printable character.
The name RSA is an acronym for the surnames of three inventors of this algorithm: Ron Rivest, Adi Shamir, and Len Adleman. They formed a company, RSA Security, which published several standard documents called Public Key Cryptography Standards (PKCS). These documents describe several aspects of cryptography.
One of the most popular of these documents, PKCS #7, defines a binary format for signed and encrypted data called the Cryptographic Message Syntax (CMS). CMS is now used in many popular security protocols, including secure sockets layer (SSL) and Secure Multipurpose Internet Mail Extensions (S/MIME). Since it is a standard, it is also the format of choice for when applications need to exchange signed and encrypted data between several parties.
source: http://msdn.microsoft.com/en-us/magazine/cc163454.aspx
Managed, Unmanaged, Native code
December 9, 2008 at 11:08 am (Technical Corner)
Tags: Managed code, Native code, Unmanaged code
Managed Code is what Visual Basic .NET and C# compilers create. It compiles to Intermediate Language (IL), not to machine code that could run directly on your computer. The IL is kept in a file called an assembly, along with metadata that describes the classes, methods, and attributes (such as security requirements) of the code you’ve created. This assembly is the one-stop-shopping unit of deployment in the .NET world. You copy it to another server to deploy the assembly there—and often that copying is the only step required in the deployment.
Managed code runs in the Common Language Runtime. The runtime offers a wide variety of services to your running code. In the usual course of events, it first loads and verifies the assembly to make sure the IL is okay. Then, just in time, as methods are called, the runtime arranges for them to be compiled to machine code suitable for the machine the assembly is running on, and caches this machine code to be used the next time the method is called. (This is called Just In Time, or JIT compiling, or often just Jitting.)
As the assembly runs, the runtime continues to provide services such as security, memory management, threading, and the like. The application is managed by the runtime.
Visual Basic .NET and C# can produce only managed code. If you’re working with those applications, you are making managed code. Visual C++ .NET can produce managed code if you like: When you create a project, select one of the application types whose name starts with .Managed., such as .Managed C++ application..
Unmanaged code is what you use to make before Visual Studio .NET 2002 was released. Visual Basic 6, Visual C++ 6, heck, even that 15-year old C compiler you may still have kicking around on your hard drive all produced unmanaged code. It compiled directly to machine code that ran on the machine where you compiled it—and on other machines as long as they had the same chip, or nearly the same. It didn’t get services such as security or memory management from an invisible runtime; it got them from the operating system. And importantly, it got them from the operating system explicitly, by asking for them, usually by calling an API provided in the Windows SDK. More recent unmanaged applications got operating system services through COM calls.
Unlike the other Microsoft languages in Visual Studio, Visual C++ can create unmanaged applications. When you create a project and select an application type whose name starts with MFC, ATL, or Win32, you’re creating an unmanaged application.
This can lead to some confusion: When you create a .Managed C++ application., the build product is an assembly of IL with an .exe extension. When you create an MFC application, the build product is a Windows executable file of native code, also with an .exe extension. The internal layout of the two files is utterly different. You can use the Intermediate Language Disassembler, ildasm, to look inside an assembly and see the metadata and IL. Try pointing ildasm at an unmanaged exe and you’ll be told it has no valid CLR (Common Language Runtime) header and can’t be disassembled—Same extension, completely different files.
The phrase native code is used in two contexts. Many people use it as a synonym for unmanaged code: code built with an older tool, or deliberately chosen in Visual C++, that does not run in the runtime, but instead runs natively on the machine. This might be a complete application, or it might be a COM component or DLL that is being called from managed code using COM Interop or PInvoke, two powerful tools that make sure you can use your old code when you move to the new world. I prefer to say .unmanaged code. for this meaning, because it emphasizes that the code does not get the services of the runtime. For example, Code Access Security in managed code prevents code loaded from another server from performing certain destructive actions. If your application calls out to unmanaged code loaded from another server, you won’t get that protection.
The other use of the phrase native code is to describe the output of the JIT compiler, the machine code that actually runs in the runtime. It’s managed, but it’s not IL, it’s machine code. As a result, don’t just assume that native = unmanaged.
(sursa: http://www.codeguru.com/columns/Kate/article.php/c4871/)
OLTP Applications
December 2, 2008 at 3:40 pm (Technical Corner)
Tags: OLTP Applications
OLTP applications are often used to capture new data or update existing data. An order-entry system is a typical example of an OLTP application.
OLTP applications have the following characteristics:
