We had a mid-sized group at the meeting tonight – 13 people in attendance.

Sandy Roach began our meeting with the second part of his presentation on Delegates and Events.  This time we focused on Events and how Visual Basic syntax looks different for events as opposed to delegates.  Where a delegate is essentially a function pointer, events are the Visual Basic implementation of the Observer pattern.  An event publisher defines an event and maintains a list of objects interested in receiving messages about that event.  When the event is raised, each of the interested objects, or subscribers, is notified and their event handling code is executed.  Multiple subscribers can register interest in an event, and the object actually defining and registering the event is not notified whether or not any subscriber actually receives the event.  Sandy showed us several demos illustrating events – two console events and one familiar GUI app showing button clicks raising events.

 After Sandy, I took the floor and showed off a 100 level view of DotNetNuke.  We looked at what web portals are in general as well as what kinds of functionality you get out of the box with DotNetNuke.  We examined several of the modules, their edit pages and their admin pages.  We looked at how DotNetNuke supported multiple portals from a single install.  After talking about DotNetNuke in general, we discussed the upcoming DotNetNuke project, where we are going to build a working module in the VB.Net group and turn it over to the open source community.  After we talked about DotNetNuke, we took a quick look at Windows SharePoint Services and how that differs from DotNetNuke.

— Matt Ranlett

posted with BlogJet

Sandy Roach began the group meeting with a presentation of delegates and event handling.  Sandy tried to show us some simple examples of delegates in Visual Basic – including a sample which uses delegates to invoke a class’s instance and shared (static) methods.  Sandy also covered multicast delegates, which invoke multiple methods from a single call.  The power of delegates is that you can write code to call a single method, and then use delegates to have that one method call actually make calls to multiple methods.

Reading that sentence, it seems unclear.  So let’s try it with an example.  Suppose we have a program which deals with books.  We have two significant functions: PrintTitle and Totalizer.  If we create a delegate for each of those two functions, we can pass the pointer to the functions into a method call: ProcessBooks.  ProcessBooks with then either print the title of the book or perform the logic in the totalizer function, depending on which delegate was passed to it.  Notice that these two functions do nothing like each other – one handles strings and the other handles numbers.  The fact that the delegates for both have the same signature (number of parameters) means that you can use either delegate from the same method call.  Check back with the original post I wrote covering D’s presentation on delegates to the Mobility User Group.

— Matt Ranlett

posted with BlogJet

Jim Wooley and I showed the group a little higher level material this time.  Jim showed off Generics, using the WhiteHorse class designer and separate code implementations contrasting inheritance, interfaces, and generics.  Using simple examples he showed us how generics preserve Intellisense and provide faster runtimes over 100,000 iterations.  Despite being a contrived example, we saw clear differences in performance over significant numbers of element access.

I showed off the Observer pattern using the example provided by the Head First Design Patterns book (this went on the white board) and an article from OnDotNet where a reproduction of a binary clock sorta demonstrates the concepts of an observer pattern.  The thing I learned most from my own presentation is that I need to spend more time reading that Head First Design Patterns book.  I felt like I understood what I read, but I had a hard time explaining it in a way that made sense to everyone else.  Actually, I had a hard time explaining the example they used in the book to illustrate the bad way to do things.  Everyone got the correct “pattern” method right away.

— Matt Ranlett

posted with BlogJet

Richard Conn introduced the Academic Relations Program – where Microsoft attempts to establish a relationship with various universities around the country.  Pretty much what this means is discounted Visual Studio and Office licenses for universities and university students.  Microsoft has even started to reach into the high schools, with 20 high schools in Atlanta alone participating.  If you have a high school student or college student interested in the computer sciences, Microsoft offers some excellent internships and scholarships.  Another interesting facet of the ARM program is its tie to Microsoft Research and a curriculum available to all for teaching Microsoft technologies.

David Chappell introduced himself by making sure that everyone knew he isn’t Dave Chappelle.  Nor is he Dave Chappell from Sonic Software (who ironically also writes books and give technical presentations on enterprise messaging).  After some fun at his own expense, David jumped into his presentation by postulating that there is always some kind of application architecture for enterprise systems.  This started with mainframes, moved on to client/server systems, and then on to multi-tiered architectures.  We may now be on the verge of shifting into the fourth evolution of enterprise systems, service-oriented architecture.  The reason this shift is possible now and not before is due to the global vendor agreement on how to consume web services.  Service-oriented business logic needs to rest on a foundation that is standard and ubiquitous.  On Windows, this platform will be Indigo.

In the simplest sense, Indigo is a bunch of C# classes that extend the .Net framework with a new namespace.  Indigo communicates through SOAP messages, functioning as an über SOAP stack.  This unifies existing MS technologies (ASMX, .NET Remoting, Enterprise Services, WSE, MSMQ) for distributed applications.  It also provides interoperability between .Net apps and others (EJB and WebSphere).  Finally, Indigo offers the idea of explicitly building service oriented applications.

An important note is that Indigo is not backwards compatible with existing .Net distributed technologies.  .  Indigo actually implements much of the functionality of the existing technologies, including SOAP over networking channels and many of the WS-* standards.  Once Indigo is release, Microsoft will no longer be enhancing the existing technologies.  Indigo will not replace the existing technologies, and will not prevent those technologies from working.

Service-Oriented Applications are generally abstracted into Data (relations), Logic (objects), and Presentation (GUIs).  Indigo fits into this picture between the logic and presentation and can be thought of as Access to Services.  In the past, the link between Data and Logic has been the mapping of tables to object hierarchies and of SQL types to Java/CLR types.  When the object-oriented Religion hit the world, OODBMS systems hit the market, only to fail.  It turns out that mapping between the relations and objects is easier.  Similarly, when the object religion hit the relationship between Logic and Presentation, Microsoft introduce a way to expose object interfaces –> COM and DCOM.  That turned out to be very painful.  Indigo goes back to the concept of mapping between services.

Having covered the basics of Indigo’s intentions, we now looked at code. 

To create an Indigo service, you must implement a service class – the methods the services provides.   You must select a host – the app domain and process the service runs in.  Finally you must specify one or more endpoints in which to access the services.  You have 2 methods for implementing a service class – mark a class with the ServiceContract attribute. Or mark an interface with the ServiceContract attribute then create a class that implements the interface.  A caution – Indigo attributes (OperationContract) and C# modifiers (public, private) are completely separate – you can tag a private method with an OperationContract, thus exposing it to applications OUTSIDE the AppDomain.  However, that same method is private within the application.  David tried to convince us that this is actually a good idea by explaining that you can create a facade of classes which invoke internal methods and expose their methods as services.  However, the facade of classes are not supposed to be called from within the application.  The group seemed leery of this – much grumbling about a new “method type” was heard.  My personal impression is that this seems to be an attempt to encourage good design (i.e. – the Facade pattern) on future projects. 

Additional options in Indigo development: One way calls adds a modifier to the OperationContract (IsOneWay=true) for events.  Duplex contracts for both the client and service invoking operations in the other.  Message contracts allow working directly with the SOAP messages.  all data sent and received by operations must be serialized and de-serialized.  The way that they are serialized is based on the data contract.  To create and pass your own types or enums, you must define a data contract (more attributes).

A quick aside: SVCUTIL can be used to generate a skeleton service class from WSDL contracts if you want to design your interface contracts before writing code, or contract first development.  By contrast, writing the code first and adding the ServiceContract and OperationContract attributes as needed is called code first development.

When defining a host, you can host a service in an arbitrary process (exe, NT service and winform/avalon processes) or host a service in IIS or the Windows Activation Service (WAS) – a lite webhost for machines not running IIS.  An app or service would use the ServiceHost generic type.  IIS/WAS require virtual directories and a .svc file.  Just like ASMX, an instance of the service class will be created when a client request arrives.

Finally, you must specify an endpoint – every client connects to a specific endpoint.  Every endpoint has 3 things: an address (where to find it), a binding (how to communicate), and a contract (what can it do).  Addresses are usually URIs.  Bindings wrap together may aspects of communication such as protocols for conveying SOAP messages (HTTP, TCP, etc) security options, support for wS-* specs, and more.  Several predefined bindings will ship with Indigo but custom bindings can be created.  An example of a predefined binding is BasicProfileBinding which conforms to WS-I Basic Profile 1.0.  WS ProfileBinding supports WS-ReliableMessaging, WS-Security, WS-AtomicTransaction, and other WS-* specs.   NetProfileTCPBinding sends binary encoded SOAP with support for reliable messaging, security, and transactions directly over TCP (Indigo to Indigo only).  One service can expose separate endpoints, each with a different binding for different clients.  Contracts are the name of the class that the endpoint exposes (service class or interface).  Endpoints are likely to be defined in config files, but they can also be added directly within the code assembly.

To create an Indigo client, create a channel to a service (typically hidden by a proxy which has been created by SVCUTIL or Visual Studio).  Clients also specify a specific endpoint that they will communicate with.  That’s about it – nothing very complex.

Services built on Indigo can be reliable, secure, transactional, and queued.  Indigo also offers reliable messaging; raw SOAP doesn’t guarantee reliable message transfer but some of the Indigo bindings such as WsHttpBinding, support WS-ReliableMessaging.  However, WS-ReliableMessaging doesn’t directly support message queuing – this is still an area where the vendors can’t agree on a standard.  Since that the world in general and Microsoft in particular has caught the Security Religion, Indigo allows for security configuration via authentication, message integrity, and message confidentiality.  Indigo also uses the .Net security model and the PrinciplePermission concepts.  Indigo transactions are built on the new 2.0 System.Transactions namespace.  Now transactions are separate from state management (different from Enterprise Services, COM+, and MTS).  Indigo apps can use System.Transactions explicitly or can use OperationBehavior attributes (which use System.Transactions under the covers).  Indigo supports queuing by running on MSMQ as the transport.  This means queuing only works on the Windows platform.  There are predefined binding choices which wrap queuing.

When considering upgrading to Indigo services, keep in mind that all existing apps will continue to work.  However, if you do decide to upgrade, keep in mind the following questions.  Will my Indigo app and apps built with existing technologies be interoperable and will my apps be portable?  The Indigo team says yes to both questions for ASMX.  Remoting will not be interoperable.  Enterprise Services interfaces can be wrapped with an Indigo-supplied tool.  ES clients will communicate use an Indigo moniker.  WSE 1.0 and 2.0 are not interoperable or portable.  WSE 3.0 will be interoperable AND portable, but it hasn’t been released yet.  MSMQ is interoperable using MsmqIntegrationBinding, but portability is not a simple task. 

Indigo vs Biztalk.  Indigo is a platform for building services on .Net.  Biztalk is an integration tool which maps between various heterogeneous environments.  Biztalk already has adapters for technologies like MSMQ and SQL.  Expect an Indigo adapter in Biztalk soon.

There is a March CAP currently available for Indigo and we expect the Beta 1 of Indigo in a matter of weeks.

Questions from the audience included:

Indigo talks to a service, what do I get back, a Dataset?  Actually you get XML (SOAP), but the data in the message is some kind of serialized object.  So it could be Dataset or objects.

What about the rich type support of Remoting?  Indigo can serialize any .Net type when talking to other Indigo services.  However, when interacting with other environments, use contract first development to ensure data type interoperability

How will Indigo handle big objects like Datasets?  Indigo serializes an object sent to it and drops it on the wire.

MSMQ has a max message size, how does Indigo use MSMQ to transmit larger objects?  MSMQ is a transport mechanism like TCP – large files are broken up and sent across the wire in discrete chunks.

Does Indigo require full trust to run on a machine like .Net Remoting does?  David Chappell wasn’t, but Doug Turnure doesn’t think so.  Research is required.

Can you serialize custom types?  Yes with a data contract.  Alternatively you can drop in your own seralizer.

I ran across this link a while ago in my RSS aggregator and thought I’d post it here as it’s extremely pertinent: Don Box’s Five Minute Indigo Challenge.

— Matt Ranlett

posted with BlogJet

We had a few new faces at the VB.Net meeting tonight.  After a bit of social chatting, Jim Wooley started the meeting with a presentation of the FileSystemWatcher done in VS2005 Beta 2.  For the sake of simplicity, we went with a Windows Forms applications.  Take a form, drop on a ListBox and a FileSystemWatcher control.  A FileSystemWatcher component basically does what it sounds like – it watches the file system for some file and some event.  You can filter by file type (ex. *.txt) and you can filter by event (changed, created, deleted, etc.).  With this really simple demo, we were able to see that the operating system raising events to our code.  Something we did notice is that the OS throws several events where we might only expect one event.  For example, open Notepad, type some text, and save it into your monitored directory.  You’ll see that you get CREATED, DELETED, CREATED, CHANGED, and CHANGED events.  So you’ll want to do error handling to prevent yourself from acting on the wrong one of those events.  Extremely simple, but a great demo to show how useful the FileSystemWatcher can be.

The next presenter was Harrell Perlman, showing us Avalon.  If you plan on taking a look at Avalon, you need to have XP service pack 2.  Longhorn’s betas are not supported yet.  You’ll also need a beta copy of VS2005 to work with it.  Harrell had a heck of a time getting his Virtual PC installed with the WinFX and Avalon, so he spent a good deal of time making sure that we’d understand the installation procedure.  WinFX is an extension of the .Net Framework that is utilized by Avalon (meaning that Avalon runs entirely on managed code).  Avalon uses XAML (a flavor of XML) to describe the layout and ties to code behind classes for event wiring.  We’re really early in the Avalon lifecycle (still Alpha) but there are already a wealth of articles discussing Avalon concepts.  Download the Avalon, WinFX, and (possibly) the LongHorn SDKs, install them in a Virtual PC or Virtual Machine, and go!  We took a quick look at a demo or two to see what the XAML markup language looks like.  The general reaction of the group was that we didn’t really know where we were going with XAML.  To me personally, it looks like the ASP.Net seperation of the presentation layer and the UI Process Layer.

Dan Bredy was presenting an article from Mike Gold (VBHeaven.com), recreating the W2 tax form.  The program uses GDI+ to render the content of some textboxes and place them directly onto an image of an actual W2 form.  Basically, set the background of a form to an image.  Place a bunch of textboxes and checkboxes on the form.  Then use the DrawString function to render the text directly onto the image (you basically can’t see the textboxes).  This takes place during the print preview portion of the application.  This makes use of the System.Draw.Graphics namespace to render the image and to draw the text from the various textboxes onto the image based on the location of the actual control.

— Matt Ranlett

posted with BlogJet

VB.NET re-cap from 4/20/05.  We checked out how to put scripting code into an Windows Form application.  Stephen had a great test harness for using a function to perform a task based on the two variables he put in.  He would change the script in the Windows Form and then take the script from the textbox and put that into the application.  You could compare this to writing C#, VB.NET, or any other language on the fly.  Something very similar that we talked about was using the CodeDom class to write code on the fly.  Once we finished up with our discussions of how to use this in a business case we moved on to the new features of VB.NET 2.0 and VS2005.  Dan gave an overview of some of the great new features like operator overloading.  He demonstrated some of the features with demos and fielded questions about the new features that he had been looking at.  

—Brendon Schwartz

Posted with BlogJet   

Traffic was bad so we had a slow start to the night, but since we had 3 presentations on reporting we had to get started at 6:30.  Jim started the night telling everyone what we had in store which was Active Reports by Jim, Steve with PDFLib and XSL-FO and finally me with Reporting Services. 

Jim started out with Active Reports which gives the end user the ability to create the reports in addition to the developers.  The end users can create the report, but you will need to create the datasource in the back end ahead of time.  You can pass in classes or objects instead of a datasource for people that use things like CLSA.  Once you install active reports all you to do is add a new file from the Add New Item selection and then if you are familiar with access you are good to go.  If you know Microsoft Access, Crystal Reports, or Reporting Services you should be very familiar with Active Reports.  To add it to a winform all you have to do is create a winform and add the report to it.  Active Reports by Data Dynamics. Standard Edition is about 499 and the pro version is 1299 per developer.  All of development for Active Reports is integrated into Visual Studio 2003 so you don’t have to add anything new.  The system comes with an end user designer with the professional version and gives the users the ability to create a report without have to install Visual Studio, but gives the same look and feel.  Some things it doesn’t do well in version 1.0 is charting, they don’t give you the source, support is great, very quick and prompt,  you don’t have drill down functionality.  The features that Jim really pointed out was the fact that you can program against the entire coding model.

Although traffic was bad we still had a big crowd eventually show up.  Note to self: A good thing to do would be to do a performance test against the reporting engines that most people use today.  We had an announcement for Book247 at a discount again.  If you show up to a group you may have a chance to get this discounted cost. 

Next up was Steve with PDFlib.  This presentation was all about creating PDF files.  The version he uses is a COM component, but there is a newer .NET version.  He pointed out that there are 3 ways to create a PDF file from a website 1) through an application like RS 2) component 3rd party product 3) XSLFO.  He went on to show us the 3rd party version called PDFLib which costs 450 bucks.  This version writes a file to disk with the information that you give it.  We were able to see some of the object model for PDFLib, but when it comes down to it there are many options out there and it just comes down to price and features.  He pointed out that these libraries do have a great place for on the fly changes and these libraries let you change options based on user input.  Finally we got to see a small look at XSL-FO which is taking data and changing them to a formatting object.  There aren’t many processors out there yet because this is still a new standard.  The one that we were shown was an apache version that we had to run from the command line.

Finally I went on to show how you can use Reporting Services in your projects and how you can use the web service to embed the information into a webpage or winform.  This is a good idea if you don’t want the end user to know the URL address or you want to have the report look like it is part of your webpage.

--Brendon Schwartz

P.S.  I promise Matt will be back soon to do the review =)

The VB group is one of the only groups which is not meeting in the Microsoft offices.  They get together in the New Horizons training center off of LaVista Road.  Tonight’s meeting had a smaller group than usual.  I’m assuming everyone is as busy as I am recently at work and just can’t spare the time.  I know that we’re not talking about a lack of advertising – Brendon and I have been getting up in front of every single user group announcing all the upcoming meetings for the month.  But I’m not discouraged by low turnout – quite the opposite.  Every group has been experiencing record-breaking turnout recently.

Tonight’s meeting had three speakers scheduled but only two managed to turn out.  And of the two that turned out, only one really had a presentation ready for display.  That completely disorganized, unprepared presenter was me!  But that’s a different story for a different day.

I was signed up to talk about the FileSystemObject how it differs from the System.IO namespace.  The gist of my presentation was this – the FileSystemObject is actually part of the Windows Scripting Host.  This is useful because it means that you can use the FileSystemObject outside of .Net applications.  I showed an example of a VBScript file and a JavaScript program, both using the FileSystemObject to work with disks, directories, and files.  The System.IO namespace offers more power and flexibility than the FSO does.  For example, with the System.IO namespace you can get the extension of a file with the .GetExtension method.  With the FSO you’ll have to search the file name string for the ‘.’  I didn’t have time to get a proper VB.Net sample project ready for everyone to see, so Jim came to my rescue.  He had an application he uses to read in some bizarre custom format text files.  He showed us how he could do the job with the FSO, a System.IO StreamReader, and a System.IO FileStream.  We didn’t have a good way to measure performance, but the general feeling of the group is that the System.IO namespace would be faster than the FSO.  If for no other reason, the FSO seems to require a COM Interop layer.  For those of you who might be interested in how to use the FileSystemObject in JavaScript or VBScript, check out DevGuru.com – they have the entire object model of both scripting languages and more.  Also, you should take a look at the Scriptomatic.

Brendon was the second speaker, presenting an interesting technique he found on the web to add custom properties to an enumeration.  For example, he was able to create an enumeration of integers which had associated descriptions.  This could be really valuable in cases like binary bit masking or error codes.  With this technique you can have a meaningful description associated with otherwise bizarre enumeration values.  I don’t have any links for examples of Brendon’s code yet, but he’ll be putting them up on the VB.Net site soon enough.

After the meeting we made our traditional pilgrimage to Chili’s for some food, drink, and talk.

— Matt Ranlett