When writing code in .Net some of us take many things for granted and not always keep in mind that many operations are performed in the context of the unmanaged code or in the “old way”…

File operations or legacy code wrappers are perfect example.
Just because library is available as managed code, it does not mean that everything has ability to “self-heal”.
For example in code file is open for edit with lock being placed.
If the file in not closed explicitly, it would be a responsibility of the owner process to release the lock at the time of releasing associated resources – when process is destroyed.

With garbage collection, just because we are no longer using/owning the process/object, it does not mean that it has been destroyed immediately after. GC management core will release object when it “feels” fit, therefore introducing latency into the process.

Off course, proper way would be to be more careful within the code and make sure any locks are released in managed and predictable way: Open/Close, Lock/Unlock, … Easy solution, but not always accessible, especially when working with 3rd party libraries.

So instead, we can force GC manager to “collect garbage” in-place with the following small code:

// See code follow up below
System.GC.Collect();
System.GC.WaitForPendingFinalizers();

What does it do?
First call will instruct GC manager to start the process (1), while second (2) will make sure that we wait for process to be completed.

In the case of the file locks, only after GC has released process which placed the lock in the first place, we can manipulate with the file (ex. delete, rename, move).

As it was announced Feb 21, 2008

Microsoft announced a set of broad-reaching changes to its technology and business practices to increase the openness of its products and drive greater interoperability, opportunity and choice. These changes are codified into four new interoperability principles and corresponding actions: 1) ensuring open connections; 2) promoting data portability; 3) enhancing support for industry standards; and 4) fostering more open engagement with customers and the industry, including open source communities.

Along with everything else over 30,000 pages of documentation on API has been made public.

As I said earlier, Microsoft seems to make a rough U-turn on their policies after facing a few big lawsuits in EU and many complains from developers community in past few years.

Now Balmer really can put his “Developers, Developers, Developers…” mantra in the air again.

As it was reported by BetaNews this Friday

Now developers no longer need to request access to the binary file format (for Office 2003) documentation in writing or by mail, the spokesperson said; they can now download all the documentation they need directly from Microsoft

Read a full story here.

PS. There is a small thing in the air – are all those changes because Bill is stepping aside? Off course not

No-one was allowed to look at the code for the purpose of to see how it works.

I, as a Pascal/Delphi developer for many years, enjoyed availability of internal source code of components and system functionality since it was always part of Delphi as we know it.

Well… it is about to change for MS code as well… not all the way… but…

In SD Times’ “.Net Source Code Released” from February 15, 2008 it is confirmed that Microsoft is changing its license policy in regard to source from “The .NET Framework source is licensed under the read-only reference license, the most restrictive of the company’s Shared Source licenses.” to more open version when “license does not apply to developers creating non-Windows software that has ‘the same or substantially the same features or functionality’ as the .NET Framework.”

You can find more from ScottGu’s Blog along with exploring a new license text itself which is called Microsoft Reference License or MS-RL. Scott also provides example of how to enable code reference with Visual Studio 2008.

I am sure there is always a twist in every story, but I think it is a good step forward for Microsoft.