Check this out :

http://msdn.microsoft.com/elearning/

بينما  كنت  اتجول  على  الانترنت،  صادفت  مقالا  يتكلم  عن محاضرة ألقيتها في الرياض الشهر الماضي حول المقارنة بين J2EE و NET.

اتهمني صاحب المقال بأنني قد وعدت بأن أكون محايدا تمام الحياد، وأنني لم أتوفق في ذلك. غير أني أتذكر جيدا ما وعدت به، ولم أعد أبدا بأن أكون كامل الحياد، حيث أن الكمال للله وحده. عند بداية المحاضرة قلت بأنني لست أتقاضى أي أجر من مايكروسفت، وكان ذلك حقيقة عند ذاك، قبل أن ألتحق بصفوف موظفي مايكروسفت في بداية هذا الشهر، وقلت أنني سأتجنب أن أميل إلى أي جانب ما استطعت، علما بأن اختياري الشخصي لا غبار عليه و أنني أفضل NET.، ولا يكلف الله نفسا إلا وسعها.

في نهاية المحاضرة، عاتبني عدد من أصدقاءي الميالين لNET. لأنهم شعروا بأنني كنت متساهلا مع J2EE أكثر من اللازم. أظن أنني قد كنت أقوم بمقارنة تقنية بعيدة عن العاطفة ما استطعت، و أن أكبر حجة على أنني لم أكن ميالا لجانب دون الأخر هو أن كل جانب اعتبرني ميالا للأخر.

I have been googling myself today (I never said my ego was not super inflated), and stumbled upon an a blog entry talking about the presentation on .Net vs. J2EE I did in Riyadh last month (The entry is in Arabic). There are a few things I think I should correct, as I think the remarks were not ill intended:

• The author claims that I said I would be perfectly neutral. I would have been foolish to claim perfectness in anything. I have only said that I would be as neutral as possible, and precised that I my own personnal choice was very clear, and that I prefered .Net
• The author said that I didn't succeed in being neutral, and that I was too favorable to .Net. I have had many reactions from attendees that were favorable to .Net that said that I was giving J2EE much more credit than it deserves. I believe that when people are there to discuss, we can talk in a serene and calm technical atmosphere.

What's the next step for .Net ? this might just be it ...

AspSoft  is preparing a big surprise for TechEd 2005. be there!

     The .Net "Celebrity" Auction for the benefit of Tsunami victims of Banda Aceh will start this afternoon (GMT time) at e-bay . Your bid will buy you an hour of consulting from one of the top experts, and all the money will go to the tsunami victims.

    Stephen Forte has the complete list with bios on his blog.

    Thanks to Thinktecture (and fellow .Net celebrities Christian Nagel, Christian Weyers, Ingo Rammer and Ralf Westphal from Thinktecture) who, being unable to get on board because they did not get the info on time (Travel and busy schedules play tricks on all of us sometimes) they have decided to help by picking up all the e-bay fees.

   You can click on the above link to the e-bay auction or go here : http://cgi.ebay.com/ws/eBayISAPI.dll?ViewItem&item=5552696499

   For my part, I intend to give a rather "long hour", and to deliver without much delay (notwithstanding my busy agenda).

Sony, although almost all their exisisting systems are J2EE based, has choosen .NET Framework and .NET Framework built Web Services for their new Professional Services web presence. Check it out at eweek...

    It sounds like I will be crabby on my posts this week. Although I am not seeing axis or IBM Web Services for the first time, I cannot stop myself from being horribly surprised by the programming model. I will not compain about all the times the environment (Web Sphere Studio 5.1 or test integration server crashes for unknown reasons). I simply cannot understand how they expect a developper to be working with tons of generated code, which has even a few bugs... like this line :

mc.setProperty(com.ibm.ws.webservices.engine.MessageContext.PARAM_MAXOCCURS_NOT1, _set2)

   It gets generated in the SOAPBindingStub when working with unbounded arrays as return type, but it seems that MessageContext has no such field...

   Not too long ago, I was looking at some interop problems one of my customers had, and we found ourselves forced to deal with a huge amount of generated client side generated source code to be able to pass a username and password for authentication (the version of the tools we were using simply dropped authentication by username and password when they added support for oasis...)

My main problem is not why there are a few bugs (even if they are at a very basic level and should definitely not be there if anyone is going to be using the tools in the real world), but that the bugs are in generated code, which will be regenerated when one makes changes to the source of the bean the service is built from. This means that the bug will have to be fixed manually zillions of times during the development process !!! and I have not even started to talk about maintaining the service after it is deployed... and it is not something that happens on 1 generated file, but a big number (serialization/deserialization classes, binding stub, proxy, service interface, helper classes, meta data, and other bizarre things) 

   XML Web Services are built on protocols and interoperability specifications, and the mapping between an object model and a service model should be built as a framework that encapsulates the generic way of mapping the two worlds, or on a new programming model totally built for services (message contract, service contract, channels, ports...etc.).

   That is the way Microsoft is dealing with the problem, and I think they are right in doing so. the asmx model offers an extensible easy way to map the object world to the message world, and takes care of mapping the whole thing into xsd and wsdl. This model is still OO, but it works for the OO developer. with Visual Studio 2005, and later with Indigo, the service programming model gets its implementation as a framework.

   Between the two programming models, my choice is definitely made.

   Although many might be reporting Microsoft's Friday announcement as bad or mitigated news, I only see in it great news. Here is my tqke qt the issues :

1. It is reassuring to know that what matters most to me as a developer and architect, i.e. Avalon and Indigo, are on track and going to be released in 2006 as previously announced. As for WinFS, and away from the hype, even if I did consider it interesting to deal with the amount of data that we will be faced with whithin the Longhorn timeframe, it is not as important to me as the other two tenets, especially if search is, as promissed, enhanced to a level where it becomes really efficient. here is how I view the three technologies :

• Indigo : if there is something that will change the world of computing and make the vision that Rafal Lukawiecki calls "pervasive integration" happen, it is the "Service Orientation". Off course Microsoft has been leading in the world of Web Services (asmx and WSE), but not until "Indigo" will we have the tools that allow us to start fullfilling that vision. It is the first framework that allows us to thing, design and implements in terms of SOA concepts (Data Contract, Service Contract, abstracting the services from the channels and transports). If there is any technology I am eager to see released as soon as possible, it is Indigo. This technology is really what will make development much better, and allow for the richest feature model through a coherent, mangeable model based on SOA.
• Avalon : Even though the most talked about features of Avalon are not necessarily very important to me, I am very happy they are included in the Longhorn release : media and UI unification, vector based graphics, higher shell integration, unification between thin client and rich client, ...etc. These will make applications look and feel different, but will take time before becoming mainstream, and thus are not as time sensitive.  However, what I would rather see happening as soon as possible, is a model where design is truely separate from code. that will save me and the developers I work with an incredible amount of time.
• WinFS : Although I am probably not the best person to discuss the importance of rows and columns, I see WinFS as being a very interesting way to unify various Data Formats, but I remain convinced that with or without WinFS, our documents will still live in folders for quite some some time, which means that I don't see it as a time sensitive issue. at the same time, and with Yukons support for managed types and XML types, I don't see what would stop our applications that use or can make use of large quantities of document to store those in the database. We are not yet at the phase where developers are doing it and in bad need for a better framework. I even see the delay as beneficial, because it may well trigger more custom developped solutions, and thus real world experience that will guide the final format of WinFS. I will not discuss Object Spaces here, because I truely don't see that technology to be either important or even beneficial, simply because I don't like mapping messages and objects (although I do use such an approach sometimes, I prefer not to have it formalized as if it was a best practice). The only valid reason I can think of that would make WinFS an urgently needed technology is the need for quickly finding information that resides in documents in the huge number and size we probably will have on our hard disks (or for that matter, in remote storage as well) by 2006. That is why I was very relieved to hear that the new search functionality is going to be part of Longhorn.

   last June, at the Q&A session at the Pakistan Developer Conference in Karachi, an attendee asked : "Can there be an exploitable buffer overrun in the CLR?". My answer was that it is always possible in theory... I was really tired after five sessions back to back. I did not develop my answer enough. I am not an expert on the CLR, so I post this in hope to get some comments from more knowledgeable people on the subject.

    Here are my thoughts :

1. The CLR is definitely unmanaged, and thus, in theory it can have a buffer overrun. No Developer is beyond making mistakes, and there certainly could be a buffer overrun. the problem is whether it can be exploited, and if so, how...
2. One shouldn't confuse the CLR with the .Net Framework : we develop in managed code against the built-in classes of the .Net Framework. this means that any exploitable buffer overrun that would surface in our applications would have to be there on the classes we develop. This means that if a buffer overrun on CLR is to be exploited through managed code, it has not only to be there on the CLR, but also to re-surface through some of the .Net Framework classes (calls to managed heap allocation for example, without validating values before making the call to the CLR). then, our own code would have to have the same flaw again... that means that the same flaw, applying to the very same value, would have to exist in three separate layers. The probability is so low that, even if it is theoritically possible, it remains so improbable that one should dismiss its possibility. There is a higher chance of having a class in the .Net framework itself having a buffer overrun in a native call, than having a CLR buffer overrun re-surface.
3. Can there be an unmanaged call to the CLR exploiting a possible buffer overrun ? I will address this in a coming post

    Anyway, I realize the question's main objective is to find out whether it is possible to defeat the managed code security messaging. No matter whether there is a possible theoritical buffer overrun exploit (which will be, in any case so improbable that it is virtually impossible), it is very clear that the managed code is hundreds of times more secure than unmanaged...

    Tomorrow, I'll be doing 5 sessions back to back. 4 were planned, and one of Steven's sessions (he couldn't make it to Karachi). These sessions are :

1. Mobile Web Development with Microsoft Visual Studio .NET
2. Developing Compact Framework Applications for PocketPC and Smartphone
3. Developing PocketPC Applications for a Semi-Connected Environment
4. Introduction to ADO.Net
5. Developing Performing Mobile Applications with the .Net Compact Framework

   While I am convinced the smartphone has a role to play in business solutions, I don't think it should be looked at the same way we look at PocketPCs and other handheld devices.

   The PocketPC is essentially a small PC, and its logical role in the enterprise is to extend the information system to englobe the mobile forces in the field. This means that the applications we develop for the PocketPC are essentially extensions to LOB, CRM, billing and such usual applications needed in the business processes. The only difference between them and applications that reside on the server or the desktop is that the PocketPC has lower ressources, smaller form factor, powered by batterie (limited autonomy), ...etc. If the PocketPC was as powerful as desktops, the apps we develop for it would be just the same as those we develop for the desktop. The necessity of small footprint, along with the semi-connected nature of all mobile devices imposes a certain way of development (rich client, data persistence, and eventually some connected operations when needed, essentially through web services). Although not as efficient as typing on a keyboard, the stylus typing can be decently used for data input.

   The smartphone, however, is essentially a phone (even if it is the most advanced form of phones), whith a small potential of data persitence and assisted data input. In my view, it should not (yet) be viewed as an extension to the business solutions, as much as a simple bridge between the solution that resides on the servers and the telephony or location capabilities of a phone. typically, the smartphone would be used to get some data from the system, but only in as much as that data is related to or helping on decision for making phone calls, appointments, ...etc, or for callecting prédefined data. The one handed operation of the phone, and the hardly efficient typing makes any input that goes beyond a few letters or a few digits almost impossible. On type of aplications I have found very intersting is reporting. It is linked to appointments, possibly to making phone calls (to confirm appointments, to postpone or delay commitments - which usually would involve sending messages or making phone calls) and it has predifined input (customers, tasks, ...etc) and usually only require choosing the appropriate info, and adding dates and times to them. When comments are needed, they can be dictated or voice recorded. then, the info can be synchronized back to the server - either through GPRS, or some other synchronization mechanism that requires the phone to be docked or wired to the system (like activeSync, Irda, bluetooth, or any other technique). That type of application is a perfect example of how the smartphone can add productivity and simplify some of the most painful processes.

   That is why, even though I am absolutely not fond of P/Invoke, I think it is an essential part of developing for the smartphone.

   The Imagine Cup is organized for the first time in Morocco this year, and the finals will be on Saturday May 8th.

   The event is taking place at the INPT in Rabat (Institut National des Postes et Télécommunications). I will do a keynote on future technologies...

   I think it will be fun being on the jury (if I make it, for I have a chance to spend some time with my daughter this week end)...

   This year at TechEd, there is an interesting new addition : The Cabañas at the Community Lounge. The idea is to cut the distance between attendees and speakers/experts. Here are a few intersting happenings :

• Meet the Technologist sessions : These are pretty much breakout sessions, but they are more attendee friendly in that they are smaller, and allowing more interaction with the speakers. They range from Chalk Talks to fully preped presentations with demos, in small open Cabañas. Attendees (At most, 30 per session) will have the oportunity to ask questions as the speaker is covering his topic, which, I am sure, will give those sessions a much more intimate atmosphere.
• There will be no speaker lounge at TechEd, and speakers are supposed to simply hung out at the Community Lounge. That will let the attendees find the speakers much more easily and interact much more easily
• There will be a concierge to help attendees find experts that can answer their questions. Many experts both from Microsoft and from the industry will be present in the Community Lounge at specified times, so that attendees can find them easily and discuss their subjects of interest with them.

    If you attend TechEd, don't miss the Community Lounge, it will be a fun and informative experience.

    I will be giving a Meet the Technologist session on "Writing .Net Compact Framework application that use the Telephony and Messaging APIs". If you are interested in mobile device development, come to the session and I will be glad to discuss any questions you may have. I will also be present at the community Lounge pretty much every day.

   Je me rappelle que, il y a quelques années, je me demandais pourquoi la plus grande partie des applications client riche avait un design très peu flatteur, alors qu'on retrouve du design bien plus poussé dans les applications Web. Cela ressemblait à une contradiction, puisque sur le client riche on dispose de beaucoup plus de moyen pour bien exploiter les capacités graphiques de la machine que dans un browser.

   J'avais à l'époque passé un peu de temps avant de me rendre compte (je suis peut être un peu stupide sur les bords?) que c'était parceque le modèle de développement n'était pas du tout le même. Sur les applications Web, les designers s'occupent de créer la charte graphique, et les développeurs s'attellent à ne créer que les fonctionnalités dynamiques (accès aux bases de données, traitement des interactions utilisateur, validation, ... etc). Ce qui m'avait pris un temps de réflexion était le pourquoi, avant de me rendre compte que c'était facile de créer des applications de design qui générent du code, mais qu'il faut encore que le code qui gère l'affichage soit séparé de celui qui gère les aspects dynamiques, et que HTML remplissait ce rôle. Je savait pertinament qu'il n'était pas facile de dépasser les fonctionnalités de HTML (temps pour normaliser, temps pour implémenter les nouvelles normes, puis temps pour que cette nouvelle norme soit supportée par la majorité des browser) et que cette opération prennait des années.

   Quand XML est arrivé, on pensait que c'était un bon moyen pour que, sur le Web au moins, on puisse créer du code qui exploiter facilement toutes fonctionnalités nouvelles des nouveaux browsers sans pour autant perdre la compatibilité avec les browsers ancien (différents XSLT en fonction du UserAgent). D'ailleur, on pouvait aussi imaginer que les applications client riche utilisent le même modèle en basant la génération dynamique de l'affichage sur du XML. Le problème restait que l'affichage était cintrolé par le XSLT, et donc que c'était aux développeurs de le traiter et non pas aux designers... et donc le modèle en entier cassait.

   Aujourd'hui, nous avons enfin un modèle qui permet de séparer réellement le code du contenu, que ce soit dans des applications client riche ou lèger, et ce modèle se base sur une forme de XML appellée XAML (Extended Application Markup Language). Ce modèle à été conçu par Microsoft dans le cadre de la refonte du sous système de présentation de Windows qui fera partie de Windows "Longhorn" (prévu pour 2006). Ce qui est intéressant dans ce modèle, c'est qu'il offre un modèle semblable à HTML, sauf qu'il est utilisable sur tout type de client, et que le code n'a pas a être mélangé dans le HTML (même plus que ce n'était le cas avec ASP.Net).

   Le principe est très simple :

•  Le code déclaratif (XAML) permet  une utilisation très riche des possibilités graphgiques (contrôles, documents, médias, transparence, effets, animlations, transformations ..etc). il est donc possible de faire des designs impresionnant avec XAML (ce que Adobe a très vite compris et a commencé à préparer des applications de design basées sur XAML). Ce code sera utilisé par le compilateur comme une classe partielle complètée par le la classe qui est dans le code (sans avoir à ajouter des balises ou quoi que ce soit)
• Le code fait en langage de développement qui constitue une classe partielle complétée par le XAML.

   Même si ce modèle fait partie de Windows Longhorn, on peut d'ors et déjà l'utiliser à travers les outils tels que Xamlon (interprétation du XAML en runtime, et code behind dans un code séparé) et les divers générateurs XAML qui permettent de transformer des documents Illustrator ou After Effect (ou autres) en XAML. Les résultats sont impéssioanants...

Dan Fernandez and Eric Gunnerson from the C# team have both disclosed today in their blogs some of the latest changes that will be made to the C# language in its next version (part of Visual Studio 2005). It seems those changes are made for legal reason, to comply with the FCLC commission rules.

While Dan speaks about some of the System.String changes, Eric writes about some of the keyword changes. While I love the new level of intimacy C# is getting into, I am afraid it will be quite difficult to migrate current code into the new version, and there will be no wizards nor clear migration path. Here are some examples of how current code translates to the new version :

• string str = "my 69 year old grand father" --> [Decent, FCLCCompliant] string str = "my (d) 69 year old grand father"  //I used (d) instead the new decency symbol
• the following code :

protected void Button1_Click(object sender, EventArgs e)

{

SqlCommand cmd = new SqlCommand("Select * from Users Where userName='"+textBox1.Text"' AND password='"+textBox2.Text+"'", myConnection);

if (cmd.ExecuteReader().HasRows) authenticated=true;

...

}

translates into something like :

stupid dangerous void Button1_Click(object sender, EventArgs e)

{

[PtentialObsenity()]SqlCommand cmd = new SqlCommand("Select * from Users Where userName='"+textBox1.Text"' AND password='"+textBox2.Text+"'", myConnection);

if (cmd.ExecuteReader().HasRows) authenticated=true;

...

MessageBox.Show("April Fools, thanks for reading this far");

}

The greatest yet... The North Africa Developer conference this year features the future Microsoft technologies : Longhorn, Whidbey and Yukon, alongside the deep inside .Net development sessions covering most areas of interest for the developer, the software architect and the solutions decision maker... In this second edition of the NDC, we expect 1500 attendees at the 3 keynotes and 45 breakout sessions. Among the speakers, a strong Regional Directors presence including :

• Clemens Vasters
• Scott Hanselman
• Stephen Forte
• Yann Faure
• Andrew Brust
• Sylvain Duford
• Ingo Rammer
• Eric Groise
• Goksin Bakir
• Malek Kemmou

    When my friend and rock star speaker John Alexander told me that there was a conference on .Net in Kansas City in june, I didn't take a second before I wanted to be there ... So I return to the midwest as a conference speaker, after I left it when I was still a student 13 years ago.

   As some may know, I have spent a few years in Wichita, Kansas during my university years, and driving the 3 hours I needed to get to KC was a weekend habit (Actualy, I used to drive to Lawrence, KS to visit some friends at Kansas University on saturdays, and usually party out there, before heading to KC in the morning to spend my day over at Worlds of Fun and Oceans of Fun). But since I left Wichita in 1991, I have never been to any part of the Great Plains (except for about a week in Chicago in the 1996 - or was it 97 ?) ...

   Last week, one of my greatest friends (I call her my sister) that I have lost contact with for the last 12 years found me through google ... Off course lots of things happen in such a long time, and I am very happy to be able to see her.

    So, somehow, the midwest is calling ...

   Si les Web Services nous ont rendu la vie plus facile, il n'en reste pas moins que seule une bonne approche permet de réellement réussir l'interopéropérabilité. Des problème simples peuvent rendre un Web Service beaucoup moins interopérable que l'on ne l'aurais prévu... par exemple, renvoyer un DataSet non typé peut casser toute logique d'intégration (car rares sont les plateformes capables de générer à la volée un objet à partir d'un schéma XSD durant l'éxécution, et d'en sortir quelque chose d'intelligible - qui ressemble à un DataSet - sauf si on intervient au niveau du proxy pour mettre en place une logique de traduction en un format dynamique utilisable - et même cela n'est pas toujours très utile pour la suite du traitement...). J'ai vu dernièrement un cas où le simple renvoi d'un tableau d'objets très simples renvoyé par un Web Service écrit sur Websphère Studio posait pour la génération de proxies sur .Net ... le format de la sérialisation faisait que dans le corps du SOAP, il n'y avait plus d'élément racine (ce qui est une interprétation légitime de ce qu'est un tableau - une simple séquence d'éléments...)

   Une façon de dépasser ce genre de problème est de penser que finalement, ce que l'on recherche, c'est de baser les échanges sur des messages, et donc sur un contrat qui spécifie les formats, le transport et les destinations ... c'est à dire sur le WSDL ... Dès que l'on pose le problème ainsi, on voit que l'approche de créer un service et de le laisser générer son WSDL n'est pas la bonne, mais plutôt de créer (ou générer) un WSDL (le contrat), puis de l'implémenter ...

    A partir du WSDL (qui devrait donc respecter le fait que l'échange comprend un message/document puis un message de réponse), on peut facilement générer une interface/classe abstraite (dans .Net Frameword SDK ou outils Visual Studio : utilitaire wsdl.exe avec option /server).

   Une fois l'interface faite, on a la garantie de respect de contrat, et on n'a plus qu'à créer une classe qui implémente cette interface et qui servira d'implémentation pour notre Web Service ...

   Coté client, il suffira de générer le proxy (qui dans tout outil réellement fait pour les Web Services, va nous générer des objets à partir des formats/schémas des messages inclus dans le WSDL). On se retrouve donc avec des objets intelligibles (dans .Net, les schémas sont rapatriés, et souvent, on peut en créer des DataSet, et simplement caster le type de renvoi dans les méthodes du proxy vers le type du dataSet, et on se retrouve avec toute la richesse des laison de données dans notre couche présentation...)

    Mono est  une implémentation Open Source de la Common Language Infrastructure (communément appelée .Net) par la société Ximian. Cette implémentation s'adresse aussi bien à Unix et Linux qu'à Windows (en tant qu'alternative à Microsoft.Net).

    Aujourd'hui, Youness Habibi de Casanet va nous présenter, dan le cadre du "Morocco .Net User Group (MugNet)", le projet Mono, ainsi que la portabilité du code compilé entre Microsoft .Net et Mono...

    La rencontre se passe au siège de Casanet au Technopark Casablanca, 8ème étage, à coté de Marjane Californie, à 16h.

   Tous le monde sera le bien venu.

I really like it, but I hate Red Hat...

    Although I had followed the mono project (Ximian's implementation of the CLI), and even talked about it in short words many times, I finally made my mind to really see it...

    Actually, I didn't just think I should do it, but it was in preparation for a talk that Youness Habibi will do for the Morocco .Net User Group, and I had promised to assist him (as if I had any idea about it)...

   It was quite an experience, and actually we were helped by Mr. Lebbadi of Atrait for compiling and configuring mono(A nice Linux guy, who didn't even say anything harsh to me - except mybe saying something in this line : are you as open to others as Microsoft). That help was crucial, for neither I nor Youness had ever really touched a Linux beyond the user interface and maybe some "vi"...

   Well, how happy we were when the hello world "mono style" worked and we had that "mono:: is alive and well..." on the screen. That was only few minutes after Morocco's victory in the mid-final African Soccer Cup, and Casablanca was going wild ... Still, we almost topped the cround's noise when we were rejoicing after we copied the .exe to windows and it worked...

   Tomorrow, we are going to start doing some serious tests on mono : (Data, Web Wervices, WebForms, WinForms...)... Long live the world of portable .Net IL ...

Can memery allocation (non garbage collected) be done with VB .Net ?

Regular answer : No. C# can do unsafe (non garbage collected) code, and VB.Net cannot

Hideous Answer : Well, yes it is far from being Elegant, but as my good friend and impressively clever RD Clemens once told me in the middle of a discussion on .Net vs. COM : "There can be no purity in software development". So here it is :

    There is full set of Memory management APIs (http://msdn.microsoft.com/library/en-us/memory/base/memory_management_reference.asp) that can be used to do memory alocation (both on the heap and on the stack), copy memory, get a handle to allocated memory, ...etc.

    VB can do PInvoke ...

   PInvoking into Kernel32.dll (or Coredll.dll in Windows Mobile) makes VB capable of dealing with such issues... which is only usefull in very special cases (using other APIs accessible through PInvoke and making sure there is no garbage collection on the arguments passed to the native APIs is the only use I ever needed them for - and only because I had to show VB.Net code (besides C# code) in presentations ...).

   It is not very hard to wrap those calls into some Utility class, and then use it for allocating memory and geting the handles to the objects, which can easily make the code somewhat more elegant ...

   Example (MSDN Article by Derek Mitchell) :

http://msdn.microsoft.com/library/en-us/dnnetcomp/html/netcfphoneapi.asp

   Have Fun ...

 

Can memery allocation (non garbage collected) be done with VB .Net ?

Use the comments to answer ...

The MDC is a great information source for Developers. Started last year, the MDC is becoming "The" Microsoft conference in the middle east ...

For those who missed the PDC (Los Angeles, October 2003), this is a great opportunity to have a look at the future with Longhorn, Yukon and Whidbey ... The three products that will change Microsoft technology, and place managed code at the center of every Microsoft product ...

This year, the conference will be opened by Bill Gates himself (for the first time in Middle East).

There are a few of my friends and fellow RDs speaking :

Stephen Forte

Patrick Hynds

Goksin Bakir

Selçuk Uzun

Hossam Khalifa

For myself, I'll be giving 4 sessions. 3 sesions on Office System development (using XML in Word and Excel, InfoPath, and Visual Studio Tools for Office), and a mobility session on developing mobile applications with the compact framework (I will dwell quite a bit on smartphone development, on performance considerations and tips, and I will introduce the new mobility features of Visual Studio Whidbey).

I have many times encountered the issue of allowing people to print some content from a web form, and usually the answer is one of the following painful and not very convincing solutions :

• ActiveX : having an activeX component handle the printing of the info on the page . This is just one more thing from the COM deployment hell era ...
• PDF : giving a link to a dynamically generated PDF has been, for quite some time, the best way out of the issue. most users do have a PdfReader, and it works ... the problem here is simply that you need server side processing of the info into a Pdf document, while the Pdf document is not part of the process at all (unless there is a requirement to let people save the doc whithout being able to modify it) ... this is a return to the Pluming era ...

Well, the main problem here is to be able to act on the client side, and do some rich functionnality ... wait a minute, there is something called Zero Touch Deployment, is there ?

The problem is, you are not supporting client that don't have a .Net Framework installed ... but, isn't that like Pdf ? the only difference is that .Net is newer, and is not on most people's machines, and does not even exist for many operating systems (yet). Well, I am lucky, because when I look at statistics of browser usage in Morocco (At least if I can trust the most visited portals), more than 95% of all internet users have machines with Windows 9x and up. Unix/Linux users are marginal, and pre-Windows 95 almost non existant ... I guess it is one time one has to be vicious, and pull out some scheme to make those users install CLR, and printing has made a great job of driving adoption of Pdf ...

So, here is the scheme : Have a smart client app that gets the info in HTML or XML (with XSLT) through a web service, and print it on the client. put that up on some highly visited site, where printing is an important functionality. Then, on the Web Pages, just test if the client has CLR , and if not(and is runing windows), redirect (with all due respect and info that he needs to install an app to be able to use printing) to .Net Framework redistribuatble installation (With code access security settings that will permit execution and printing, once again after having notified the user). Once the client has CLR, just redirect to smart client app, and pass the necessary request params that will allow the web service to retrieve the document.

Wait a minute, I tried to do this, but there is no way to pass params to the smart client app. Url formating will not let you pass command line args. If you pass request params, you have two issues : retrieving those params, and you can do that in different ways :

Environment.GetCommandLineArgs()  or  Environment.CommandLine

AppDomain.CurrentDomain.domain.GetData("APP_LAUNCH_URL")

That will give you the full Url, and you can parse it to get back your params. The problem now is that you have made the WebService proxy go crazy. It will try to see if there is a config file (for some obscur reason), and will be using your Url and appeding .config to it, and there is no way out. Not quite so,  thanks to Chris Sells and his article on msdn . You can add an HttpHandler to the application serving your smart client, so that it handles the .exe, and the .config...

There, you have completed the trick, and good luck hunting unCLRed clients ...

Suite à la création du User Group MugNet, il semble qu'un certain nombre de critiques se sont produites dans la le milieu informatique au Maroc. Si je ne suis pas, par nature, un polémiqueur, il y a cependant quelques réflexions qui me gènent. Par exemple, sur le group MarocIT, une remarque a été faite en ces termes :

Le .NET n'est pas reconnu actuellement comme un "standard
technologique international". Comme une initiative qui vise aux
développement des nouvelles technologies, c'est une bonne chose de
créer ce genre d'ONG. Cependant, si c'est sponsorisé par Microsoft
pour essayer d'imposer sa plateforme face à la concurrence farouche
des "open source", ca ca devient de la pub/sponsoring pur et simple
sans aucune valeur ajoutée pour notre pays !

Une autre remarque est carrément une attaque :

Je ne savais pas que .net était un "standard technologique international" ni que Microsoft avait le droit de faire de leur département marketing développeur une ONG!

Bien que le terme ONG me dérrange pour décrire un User Group, je ne comprend pas comment on a pu nous assimiler au département Marketing développeur de Microsoft. Comme je ne peux pas croire que quelqu'un va, par pure méchanceté nous attaquer avant même de savoir qui nous sommes, je suppose que quelque chose a dû être mal interprétée ...

Je peux penser à deux choses différérentes comme possible source de confusion :

1. Que l'on ait interprété .Net comme étant Visual Studio .Net

    Cela est le moins grave, car, effectivement, il est compréhensif que l'on puisse confondre la technologie .Net avec l'implémentation la plus utilisée sur cette technologie. Pour cela, je préfère, même si je pense que ceux qui lisent ces lignes le savent déja, préciser un peu ce qu'est la technologie .Net. Initiée par Microsoft, la technologie .Net, ou plus précisement la "Common Language Infrastructure", est une spécification proposée par Microsoft, HP,Intel, Fujitsu, ISE et Monash University, et standardisé par ECMA et ISO. Cette spécification est précise (Langage intermédiaire défini, spécification du Runtime, bibliothèques de classes, ...etc.). Les implémentations de cette technologie sont multiples, et les plus visibles sont la multitude de langages par différents éditeurs (Microsoft, Borland Delphi et C#, Sybase Python et PowerBuilder, ActiveState Perl, Fujitsu/Lahey Cobol et Fortran, les langages académiques tels que Mondrian, Haskell,  Component Pascal, Scheme, Mercury, ...etc) ainsi que le runtime Mono de Ximian (nouvellement filiale de Novell), les outils de développement (add-ins DB2 de IBM), et beaucoup d'autres.

2.Mon titre Microsoft Regional Director

   Si je n'ai pas souvent eu à m'expliquer sur mon titre, c'est que, en tant que consultant, je suis relativement connu dans le milieu, et même si je me sens proche de Microsoft, mes clients savent que je ne suis guère un fanatique des technologies de Microsoft. Ils savent que je suis totalement convaincu par .Net, mais que je suis là, avec eux pour d'abord aider au succès de leurs solutions, et que je ne recommanderais pas une technologie Microsoft si elle n'est pas un bon choix pour eux. Je comprend par contre que peut être, on puisse l'interpréter comme un titre donné à quelqu'un du département Marketing développeur de Microsoft (bien qu'un tel département n'existe pas en Afrique du Nord) ...

   Puisque je n'ai jamais expliqué, dans ce blog, ce qu'était un Regional Director, je le ferais en quelques lignes :

   - je suis un consultant indépendant (je gère mon propre business de consulting), je ne travaille pas chez Microsoft, ni pour le compte de Microsoft.

•    je suis reconnu par Microsoft en tant que "expert" sur leur technologies
•    j'ai des rapports d'échange d'information avec les équipes de développement de Microsoft (ceux qui développent les outils de développement plus précisément). Cela me donne accès à des informations confidentielles sur les technologies Microsoft, et me permet donc d'être très efficace sur leur technologies
•    Je ne touche pas un centime de chez Microsoft (à part quand on me commande des interventions en tant que consultant ou speaker sur des évènnements)
•    Je n'utilise pas que les technologies Microsoft (ne serais ce que pour des besoins d'intégration dans des milieux hétérogènes, ou pour des fonctionnalités où les technologies Microsoft ne sont pas bonnes ou n'ont pas les fonctionnalités voulues ...)

Au fait, c'est un titre qui m'honore, et qui est plus une reconnaissance de compétances de la part de Microsoft qu'autre chose...