Microsoft created the .Net platform for competitive reasons (Java), but also for some of the reasons that made Java successful. Moving from C and C++ and the awkward COM/OLE interfaces to a “managed” run time makes for: Safer code in that many of the kinds of attacks against web applications have come from something called “injection attacks” which affect interpretive interfaces and buffer-overrun attacks, where binary values are deliberately passed to corrupt the stack and alter the behavior of programs. More robust code in that memory leaks and overwrites are less likely in a managed environment. More portable code because the common language runtime is converted to platforms specific binary code at runtime and the programmer is isolated more from the details. Easier to integrate than COM/OLE because all managed code is generally explicitly typed and auto-help is easier to implement (The dynamic language runtime being one exception). All of these factors make it easier for 3 rd party library vendors to deliver extension libraries that integrate tightly with development environments. Microsoft’s support for .Net has resulted a very rich set of components and a lot of effort around making the platform extensible.
When we talk about .Net we really mean a collection of technologies and libraries. The execution environment includes: A Common Language Runtime (CLR) that makes programs written in a variety of languages translate to a common implementation; which improves integration and consistency. Code generation facilities make it comparatively easy to add new languages and to generate scripts without having to write a separate compiler and linker. The technology that loads statically linked components also allows dynamic linking and navigation of the types being loaded. This is not optional as with COM/OLE. It is part of the packaging of .NET assemblies. Much of the value of .NET is realized by the inclusion of a very large and well tested set of assemblies/libraries with classes to accelerate the development of very complex programs. These classes include: Collections, lists, code generators – a standard library SQL interfaces – called managed providers Communication interfaces – make services, remote function calls, socket connections and web connections easy.
The Common Language Runtime provides a context to combine software written by Microsoft, 3 rd parties like Alpha Software and custom software into an environment where the constituent components play well together. It is easy to build on the work of others to weave a more powerful software solution.
The Common Language Runtime executes the Common Intermediate Language (CIL). This is a bit of a misnomer because the CIL is actually compiled “just-in-time” into native code that executes the intentions of the CLR, but in machine code native to the platform. As a result, many different programming languages, each with features that facilitate a variety of approaches can not only execute in the same environment, but can work together. XBasic is a language that we would like to see generated as CIL as well, perhaps by translating to C#.
While many of the types built in to .NET are automatically loaded into the Alpha Five development and runtime environments (many of those in the System and Microsoft namespaces), custom or other 3 rd party libraries can be added to the environment with a couple of lines of XBasic code. Once registered, these types will be available with auto-help.
SOAP web services publish a syntax called WSDL (Web Services Descriptor Language) that makes it possible for tools to generate a client proxy that XBasic can use. With the new DotNet::Services class, you can generate the client assembly, register it and call the web service as if it were part of your application.
We’ve already discussed the right set of class libraries included with the .NET framework. Here are some more libraries that Microsoft has built on .NET as well. It is important to note that these libraries are very well tested and tuned and it makes sense to build on them.
If you look at the possible configurations where we might like the Alpha Five runtime to be, you can see that having XBasic and the rich set of Alpha Five features integrate in .NET applications and services would be a good thing for everyone. While the longer term picture will most likely include web services, windows services and windows executables as well as class libraries written in XBasic, the shorter term objective is to play well as a web application environment. Running under IIS is a high priority. The boxes in dark green show the parts of Alpha Five that make this possible.
Why .Net? It’s far more cost effective to extend Alpha Five with new features. The quality of Microsoft’s prebuilt components improves the quality of code written with them The just-in-time compiler means that code written with these components will have the performance of machine code. The ease of extending the built-in functions will make building complex applications and even adding features to Alpha Five much easier. Applications running under .Net tend to scale well.
Dot netsupport in alpha five v11 coming soon
Alpha Five Version 11 .NET Support
Why Microsoft .NET? <ul><li>Safer code (attacks via injection/overrun) </li></ul><ul><li>More robust code (Memory management) </li></ul><ul><li>More portable code (32/64/128 bit, Unicode) </li></ul><ul><li>Much easier to integrate than COM/OLE </li></ul><ul><li>Vendor support – 3 rd Party Libraries </li></ul><ul><li>Microsoft Support </li></ul><ul><ul><li>It is where Microsoft is investing </li></ul></ul><ul><ul><li>It is where Microsoft is adding features/tools </li></ul></ul><ul><li>http://www.codeproject.com/KB/dotnet/WhyDotNET.aspx </li></ul><ul><li>http:// www.netvision.lt/en/why_net_framework.aspx </li></ul>
Microsoft .NET <ul><li>Execution Environment </li></ul><ul><ul><li>Common Language Runtime (CLR) </li></ul></ul><ul><ul><li>Code Generation Facilities (CodeDOM) </li></ul></ul><ul><ul><li>Dynamic Loading of Assemblies </li></ul></ul><ul><li>Rich Set of Prebuilt Functionality </li></ul><ul><ul><li>Class Libraries </li></ul></ul><ul><ul><li>SQL Interfaces </li></ul></ul><ul><ul><li>Communication Interfaces </li></ul></ul>
Microsoft .NET <ul><li>Common Language Runtime </li></ul>Runtime – One per process Operating System User Application/Assembly 3rdParty Assemblies .NET Libraries Custom Assemblies Generated Assemblies
Microsoft .NET <ul><li>Code Generation Facilities </li></ul>VB.NET F# C++ C# J# … XBasic Common Intermediate Language (CIL) Byte-code Language Specific Compiler Native Code Just-in-time Compiler (JIT)
Microsoft .NET <ul><li>Dynamic Loading of Assemblies In XBasic </li></ul>dim Sv as DotNet::Services Sv.registerclass(“MyNS”, “String”, "system.text.Stringbuilder") dim s as MyNS::String s.Append("Hi!" + crlf()) ?s.ToString() = Hi! s.Replace("Hi", "Bye") ?s.Tostring() = Bye!
Microsoft .NET <ul><li>Generating and Using Assemblies </li></ul><ul><li>As </li></ul><ul><li>Web Service Clients In XBasic </li></ul>dim sv as dotnet::services dim DLLName as C = "c:tempMapPoint.dll" sv.GenerateWebServiceClientFromURL ("http://staging.mappoint.net/standard-30/mappoint.wsdl", DLLName) dim assy as dotnet::assemblyreference assy.filename = DLLName sv.registerassembly ("MapPoint", assy) dim Finder as MapPoint::FindServiceSoap
Microsoft .NET <ul><li>Rich Set of Prebuilt Functionality </li></ul>Base Class Libraries BCL Base Classes Windows Workflow Foundation WF Work Flow Windows Communication Foundation WCF Communications Active Data Objects .NET ADO.NET Database Common Language Runtime CLR Code Windows Presentation Foundation WPF Visual
Alpha Five Web Server Internet Information Server Alpha Five Services for .NET IIS Plug-in ASP Web Service Class Library Windows Executable Web Application Alpha Five Platform Services WCF Web Service 3 rd Party Hosting Environment Windows Service Alpha Five Services For .NET
So in sumary…. Benefits of .NET support in Alpha Five v11 <ul><li>Features </li></ul><ul><li>Quality </li></ul><ul><li>Speed </li></ul><ul><li>Extensibility </li></ul><ul><li>Scalability </li></ul>