Variables initialization in Data Layer Class of 3-tier windows application.

1) "...where should we initialize our DataSets and other Variables"…?
When it comes to "where", there is not such question about local (stack variables) as they always should be initialized locally before use. So the question should be about class members, static or not. There is no strict recipe; it totally depends of the design of the code.

2) "Does their initialization in constructor results to allocation of memory in advance?"
There is no "in advance" or not "in advance". Heap memory allocation always takes place immediately as a result of construction of all reference types. There is also stack memory consumed by local variables when a stack frame is created (for reference types, stack memory is reserved on a stack frame and heap memory is also allocated). Reservation of the memory for a stack frame usually is not called "allocation" though.

3) "Since constructor is invoked as soon as we declare any object to that class…"
Not true for "C#". A declaration of a reference type does not create and object; the pre-elaboration of the code declaring a variable of reference type without initialization makes it null; no constructor is called. (This is easy to check up using debugger.)

4) "will memory allocated for these variable… remained blocked…?"
This part of question does not really make sense. This is not such concept as "blocked memory". (If "remane blocked" should mean "remain allocated", this topic is covered below.)

[EDIT]

"Release memory":
Memory is released by Garbage Collector (GC), and not by Visual Studio but by .NET Framework (in general, what we discuss has nothing to do with Visual Studio; you compile and close it; all what happens happens in run-time of your application runs on the .NET platform).
GC works automatically (you can control some actions though); it detects all objects to be released using the following criteria: is the all references to the object is lost, it is a subject of destruction. GC can even detect the situation of isolated "island" of objects mutually or cyclically referencing each other (which can be easily checked up under debugger). Eventually, GC calls the destructors of such objects and reclaims memory. It does not happen immediately after the object becomes "lost": GC "decides" when to do it according to its own optimized strategy. In this sense, the moment of destruction is unknown; no code should depend on any certain order of destruction of the objects. This is one of the reasons by which using destructors in a good code is relatively rare; in most cases destructors are not needed.

—SA