Subsembly: the Smart Solution for Smart Cards in .NET - What is the problem?
(Page 2 of 5 )
With the release of .NET technology, Microsoft introduced a framework for designing, developing and deploying scalable, robust, quality solutions. Not to mention the introduction of new languages like C# and J#, designed to enhance developer productivity by patching up the loopholes that were present in other languages. C# and J# had inherited these loopholes from their procedural style of programming.
I’m not sure about much, but I'm very sure about the future of application development on the Windows platform. By providing efficient tools such as VS .NET, a huge code base in terms of examples, and vast online help for the .NET platform (in addition to the new languages that target the .NET CLR), Microsoft has ensured that the technology is here to stay--even if it breaks the Win32 development style.
Although the .NET framework provides a rich set of classes like the Windows forms that make GUI programming a breeze, it doesn’t offer any support for Smart Card application development. The developers who intend to include Smart Card access or support in their applications generally resort to creating their own custom Interop wrappers on the COM components or P/Invoke wrappers to access the PC/SC 1.0 Compliant native WinSCard API that is available through the Smart Card Base Components. It is really a tedious job to get it right while delivering solutions with Smart Card access is just a small part of a larger project. Most developers would like to spend most of the time on the main application that needs this access rather than trying different P/Invoke prototypes. If you’ve tried it, you understand what I’m trying to explain.
Next: What is Subsembly? >>
More .NET Articles
More By Digvijay Chauhan
