Channel 9 - Discussions by aza

Tech Off - How do I contact Intel regarding a product suggestion?

aza — Mon, 14 Jun 2004 07:55:45 GMT

Shining Arcanine wrote:

Considering Microsoft and Intel are partners, I thought it would be a good idea to ask here as I have no idea how to contact who ever makes the decisions regarding what products Intel develops/produces/sells. Anyway, does anyone know how to get in touch with Intel regarding a product request/suggestion?

If it's not confidential you could post it up to this messgae board and it will be passed along. If it is confidential then I have no idea of the approach to take, you need non-disclosures, patents etc. etc.

There is an internal web site within Intel that allows "innovation" suggestions to be put forward. The suggestions are processed by managers in the IT Innovation deparment.

Regards,
Aaron

Coffeehouse - GotDotNet vs SourceForge

aza — Thu, 27 May 2004 07:23:00 GMT

Hi,

I saw a question posted on the GloblBank wiki about why developer's aren't participatng on the GotDotNet message boards.

I don't claim to know the answer for all developers but personally I participate in SourceForge instead of GotDotNet. And indeed there are a large number of .Net based projects in SourceForge so perhaps I am not the only one.

The reasons I use for SourceForge instead of GotDotNet:

1. In SourceForge I can always read the code. GotDotNet I may or may not be able to. This has nothing to do with any philosophy towards open source it's just that as a developer it's often what I am interested in as oppossed to just getting some binaries.

2. There is a lot more activity in SouceForge. This is a chicken-and-egg argument.

3. GotDotNet seems in some ways like a Visual Source Safe for the Internet. My team uses VSS to store our code. While I would feel comfortable hosting our code in SourceForge (if it was open-source) I wouldn't feel so comfortable about GotDotNet. This is mainly due to the maturity, support arrangements and access controls in the GotDotNet system. As it becomes more stable perhaps this will change.

Aaron

Tech Off - Lack of Managed Authentication

aza — Wed, 26 May 2004 21:38:35 GMT

Seems like Intel is assuming it's full steam ahead with LaGrande and Longhorn.

http://www.intel.com/cd/ids/developer/asmo-na/eng/97003.htm

An interesting point in the article is the mention of the need for the NGSCB software to run alongside the OS and mediate access for application to secure hardware functions. So computers will now have two OS'? Or even three with the BIOS' getting more and more advanced. Sigh.. it's just as well WinFX is going to abstract away all this complexity for us poor application developers.

By the way does anybody know any of those memory drugs I am pretty sure my head is nearly full but there's still Yukon, Longhorn etc. etc. to go.

Aaron

P.S. Please excuse me for conversing with myself.

Tech Off - Configuration Files

aza — Wed, 26 May 2004 21:26:07 GMT

Rafa® wrote:

I don't even know if it's useful for something, but I was wondering...
Because, I was developing with unit testing, and I was searching a way to the testing assembly gets the ConnectionString from the Configuration file (it's still unsolved)... Then it comes up in my mind...

If you are using NUnit you can specify the configuration file for the assembly being tested. In addition if you are also using Nant it's all wrapped up nicely in an XML file for you .

Aaron

Tech Off - Lack of Managed Authentication

aza — Tue, 25 May 2004 15:18:06 GMT

Hi spod,

Seeing as how you are going to be asking some questions in the platform security area...

Is there any update on the status of Palladium (aka Trusted Computing Platform, aka NGSCB, aka La Grande etc. etc.)? Is it still on the roadmap or have the rather ironic concerns of privacy advocates caused a rethink (I say ironic because the same advocates often desire a more secure platform and not because I consider privacy irrelevant)?

One among many reasons I ask this is that from an application developer's perspective I see a big need for an application secure store. The user should always be able to remove the application, including the store, but an application often needs to have a security layer that is not dependent on the user.

An example would be a peer-to-peer application. The application wants to expose services on participating peers but only to instances of the same or designated applications. Today the only security mechanisms available, on any PC platform (since it's a hardware problem), are user based.

Aaron

Tech Off - Registry Access

aza — Tue, 25 May 2004 14:12:28 GMT

Don't the Microsoft.Win32.Registry and RegistryKey classes have everything you need? As far as I was aware you could open any key you liked, providing you had permissions, using these classes...

Micorosft.Win32.Registry.Users corresponds to HKEY_USERS, I don't have a HKEY_LOCAL_USERS (WinXP).

Aaron

Tech Off - Lack of Managed Authentication

aza — Tue, 25 May 2004 10:36:52 GMT

spod wrote:

When u say "you can sign soap requests on behalf of the user" do you mean you would like the user to be automatically assoicated with a cert / private/public key pair that can be used for digitally signing etc? Or are you just looking for a way to interface with the certificate api in managed code?

Hi spod,

Any samples coming before Longhorn perchance? .

In answer to your question no I am not really looking for more cryptographic hooks for signing, encryption etc., What's currently available in the .Net BCL is more than suficcient.

What is missing, at least for me, is the key management piece. Obviously this is not something that can be provided by a library alone it also depends very heavily on the underlying platform. What I am talking about is hooks into the coupling of Active Directory and cryptographic mechanisms.

A simple example of what I was trying to articulate in my last post is:

An application running on machine A signs a message on behalf of user A and then sends the message to an application running on machine B. The application on machine B is able to verify that the message came from user A using the platform's security services, i.e. Active Directory.

There are numerous more use cases especially around getting remote processes to use delegation and impersonation, particularly with regards to web services and remoting (IIS mechanisms are not always suitable).

I do have the managed SSPI example that is available on msdn and this has temporarily filled my gaps in the past. But I look forward to having more managed access into the Window's security infrastructure.

A positive side benefit is that my C++ got a workout trying to solve some of these problems .

Aaron

Tech Off - Lack of Managed Authentication

aza — Mon, 24 May 2004 13:38:21 GMT

Hi,

The two biggest holes I have encountered in the .Net libraries are probably NTFS file access and user authentication. I fully appreciate that shifting from a Win32 API to a new API (in this case .Net) is a "huge" task and hopefully these two aspects are coming...

In the meantime I have a question about what would be a good way to handle non-repudiability in an Active Directory environment.

The System.Security.Principal.WindowsIdentity class lets me know the authenticated user is and the System.Net.NetworkCredential class even lets me make use of the authenticated user's credentials when using IIS. But what if the application needs to digitally sign a SOAP request or do some other cryptographic type operation on behalf of a user?

I got a little bit excited with the release of WSE2 when I saw the multitude of classes and support available for digital signatures. However after playing around with it a bit I found that the classes to create security tokens from an XML signature, or similar, were all inaccessible and could only be used by way of an IIS SOAP extension, thus allowing only very narrow usage scenarios.

I appreciate that using the Win32 API it is possible to serialise Windows security tokens but this is a task that would take weeks to month(s) rather then the day(s) that we, as .Net developers, are now expected to operate under.

The ability to utilise single sign on and at the same time leverage distributed computing paradigms such as web services and remoting all require user authentication. Not having a managed API is a major, major disadvantage to being able to utilise one of the most basic services of a Windows environment!

Thanks,
Aaron

Tech Off - Error Handling, use exceptions?

aza — Mon, 24 May 2004 07:18:16 GMT

amotif wrote:

One should beware of falling into this as a default practice. Every method should be considered closely for exceptions that it may generate or that callees may generate and the effect they have on the method's work and resources. C# and VB.NET compilers don't have the Java compiler's ability to nag about exceptions you haven't explicity dealt with, so it's entirely up to you, the coder, to ensure that you won't be leaving resources in an untidy state. Many methods won't need a try-catch block. Some will. Whether you want to discover the latter at 2am during a hands-off debug session on production boxes at go-live is somewhat up to how tidy you are about exception handling.

Won't garbage collection take care of this?

Sure if you are using an exotic resource, such as external calls into unmanaged code, then there would be a need to catch and clean up. However in the 99% of cases where you are just sticking to the base class libraries is this a concern at all seeing as no explicit disposal is required, exception or no?

amotif wrote:

Another aspect of bubbling up exceptions is that the meaning of an exception changes as it bubbles up the call stack.

...
The change in an exception's meaning tends to be particularly interesting as it crosses subsystem boundries.

I agree with that point to an extent. I tend to use ApplicationException a fair bit to impart application specific error information back up the stack.

When I first started utilising exception management I used to use try-catch blocks in every method. After a while this often seemed a bit pointless, for instance in cases where a file IO exception was caught and then subsequently rethrown half a dozen times up the call stack.

Nowadays if there is not an exception condition that needs extra contextual information added (probably guilty here of verging on the lazy side of needs) then I dispense with the try-catch block altogether.

The flip-side of catching and adding contextual info is that the real cause may then be hard to find. If an invalid argument caused the exception in the VerifyHash routine and it get's wrapped in an Unauthorised exception it could send the debugging developer way off on the wrong track. Theoretically if the original exception info is maintained with the wrapped one the developer could always obtain it but if it's a big call stack with lots of wraps it could become tiresome and easily be overlooked.

aza

Tech Off - Interfaces

aza — Fri, 21 May 2004 07:47:15 GMT

clint_hill wrote:

And so I would wonder how might there be a way to still get the advantages of interfaces yet keep the flexibility of classes. Abstract comes to mind and I was wondering how you guys play this into your designs?

I use interfaces to:
1. Provide an agreed upon signature for two or more developers,
2. Provide a minimal clean access point for an implementation class.

Classes are obviously where all the magic happens and serve a completely different purpose to interfaces. As far as abstract classes go if they only contain abstract members then they are equivalent to an interface anyway.

I find I use interfaces more then base/abstract classes and polymorphism. While polymorphism is extremely powerful and useful the situations to which it is suited for don't appear that regularly.

I don't see a class as being more flexible then an interface, they are used for different things. Unlike classes interfaces can't satisfy any functional requirements but if interfaces are used wisely they can provide the code with clearer and cleaner semantics; thus helping avoid smell and make life easier for maintainers. In more complex designs Interfaces also make it easier for multiple developers to build and subsequently use the software by providing unambiguos APIs.

Aaron

Tech Off - FxCop vs Static Constructors

aza — Thu, 20 May 2004 10:38:42 GMT

Hi All,

FxCop displays particular vehemence towards static constructors: it actually displays vehemence towards a lot of things but time is short. The argument proposed by the FxCop documentation is that, "Initializing static data in explicit static constructors results in less performant code.", which is fair enough. But what if the static constructor is being used for more then just initialising static data?

For example I use a static logging class and initialise the logger in the static constructor. The logger is thread safe and I prefer to have a one stop shop for logging to make it for application wide changes. But back to the original question, why does FxCop object to static constructors when they present a valid useful purpose? Is there a reason why thread safe static constructors should be avoided?

Regards,
Aaron

Tech Off - Interfaces

aza — Thu, 20 May 2004 07:43:53 GMT

I find interfaces useful to move from the design stage to the development stage. After coming up with a rough class diagram it can be handy to use interfaces to clearly define the interactions between classes. This approach becomes even more useful when there are mutliple developers involved. I can provide the interface for my classes to the other developers much quicker then I can provide the implementation. Coding can then proceed in parallel.

One esoteric problem I am grappling with right now is due to interfaces not supporting properties. Often the shared signatures will need methods and properties. Alternative options are to use a base class and inheritance but this adds a level of semantic complexity that kind of defeats the purpose.

If a "shared" interface changes then all parties using it need to adjust their code. The benefit of using the interface in this case is that as an interface implementer you know exactly which signatures are used by consumers. Of course public accessors also do this but I think interfaces give it an extra level of clarity. I may still be tempted to change a public method signature because I was the one who made it public in the first place and no one else is likely to be using it and maybe I'll just make it private so I can change it anyway.

Regards,
Aaron

Tech Off - Error Handling, use exceptions?

aza — Wed, 19 May 2004 14:15:40 GMT

In addition isn't this a deviation from most of the other base class libraries? I can't recall ever using a reference parameter to check for an error in the .Net libraries...in Win32 yes.

Personally I think one of the strengths of .Net is its uniformity. Even if a mechanism isn't perfect for every situation it makes life a lot easier if the mechanism is already known, i.e. the same in all base classes.

IsValid and Parse (with an exception) seem a lot more intuitive then TryParse.

Aaron

Coffeehouse - What is a Program Manager?

aza — Wed, 19 May 2004 13:42:58 GMT

Interesting.

So the Program Manager is a Project Manager who gets to define their project.

"pick up and run with the ball, they go find the ball"

(Please excuse my developer's skepticism, I am still waiting to be issued with my evangelists toolkit)

I actually thought us developers already exceled at deciding what is best for the them! Surely no one else knows the customer as well as a developer? In fact who is this non-customer Program Manager and why are they dictating requirements? They don't even need the product they can just make up new requirements all day to torment the devs.

Program Manager sounds like a great job to me , I bet they get paid a lot as well.

Aaron

Coffeehouse - What is a Program Manager?

aza — Wed, 19 May 2004 06:58:42 GMT

Everyone on the video interviews seems to be a Program Manager. Do these managers actually have subordinates? Or is the use of manager referring to the software?

Just interested to know if we are getting the views of people working with the "live" code in these programs or the people managing them.

Thanks,
Aaron

Tech Off - Error Handling, use exceptions?

aza — Tue, 18 May 2004 21:53:08 GMT

I think the art of exception management is knowing where to use try-catch blocks. Over the last couple of years I find myself using less and less of them and now tend to place them only in the top level consumer classes (of course there are always exceptions).

I am more concerned with throwing exceptions as a way of tranferring information about an error condition. If an exception isn't thrown then the caller has to check for an error condition after the method call has returned. The latter can get onerous especially when the mechanism to check for error conditions varies across different modules. Exceptions present a standard way to transfer the error details and have the added benefit that they can be allowed to bubble up if the caller doesn't want to handle them.

From the msdn chapter referenced by spod one of the guidelines for exceptions is:

"Do not use exceptions to control application flow"

The reason being that exceptions are expensive. However exceptions make the code much more intuitive and the .Net base class libraries seem to ignore the guideline. I wonder if it really is that expensive in a "typical" managed application?

Tech Off - Error Handling, use exceptions?

aza — Tue, 18 May 2004 15:09:25 GMT

I recall reading that chapter in the past and subsequently becoming wary of using exceptions excessively. It's hard to disagree with what it says with regards to performance but with respect to programming flexibility and elegance exceptions are, to my mind at least, a superior approach to putting information into method return values.

The article states that exceptional paths should only be taken less than one time in a thousand. But at the same time a lot of the .Net base libraries throw exceptions at the drop of a hat.

A classic example is System.IO.File, whenever an attempt is made to open a file exceptions will be thrown if the file doesn't exist, the user doesn't have permission, the file is already locked etc. To me this makes perfect sense. If the Open method just returned false my application would then have to look somewhere else to find out why the file could not be opened.

My, rather long winded, point is that exceptions maybe aren't good in situations needing optimal performance, such as ASP.Net, but they are a pretty good way to handle and promulgate error information otherwise!

I am starting to think that I should use exceptions more in client side code rather than less. If a method has three input parameters needing validation wouldn't it be better to throw an exception to inidcate how the parameters are incorrect rather then just returning false or something?

Regards,
Aaron

Tech Off - Error Handling, use exceptions?

aza — Tue, 18 May 2004 13:31:05 GMT

Hi,

A question that I have never really found a good answer for is what is the best way to inidcate common errors in a method?

The options would be:

- Indicate using the return object. The problem here is returning false or null doesn't say much about what caused the error,

- Indicate using a return type and set an error property. This is the equivalent of the Win32 GetLastError call. Problem with this is it needs broad acceptance and since it's not done this way in the .Net base library would just cause confusion,

- Throw exceptions on any error conditions encountered. Problem with this is it's supposed to be bad practice.

The throw exceptions approach seems to me the most elegant and flexible. Obviously it brings in a performance hit but in the context of managed code is it a significant one?

The .Net base libraries seem to throw exceptions for easily detected conditions. Is the consesnus error handling approach in the .Net libraries to throw exceptions?

Aaron

Coffeehouse - [ASP.NET] the page template paradox - separating design and content

aza — Tue, 04 May 2004 21:33:37 GMT

I talked about a similar thing here a week or so ago in "Are Web Controls an Anti-Pattern?" post. I will try and take a different angle here to avoid repetition.

I have a deep philosophical problem with two (well more then two but these will do for a start) aspects of web application development:

1. Using code and markup in the same file,
2. Placing or rendering markup in compiled code.

The reasons are discussed in my previous post but I am always happy to repeat them ...

I only did a quick skim of the post you referenced (14 pages!! someone should write the book) so I don't know how deep the discussion got into front-controllers and MVC. To me this is a far superior solution compared to the current page controller implementation in ASP.Net. Incidentally one of the Microsoft architecture articles states something like that, as the application complexity increases a front-controller implementation should be considered to replace the existing page-controller one.

Over the last 18 months I have been messing around with Maverick.Net (and my own cut down, very unpolished, version MaverickLite). These frameworks allow very complete and clean seperation of the presentation and content layers as well as avoiding the two previously listed pet hates.

A quick hello world example demonstrates better then any explanation.

The heart is a workflow map which can be stored in a file somewhere, the important part is an entry like:











Where the web.config has an entry like:



The flow is:

1. Page request for helloWorld.aspx is received (the helloWorld* is a regular expression so helloWorldA.aspx and helloWorldItsANiceDay.aspx would also get serviced by this entry),
2. A controller is instantiated to build a model. In this case there is a null controller and the model is a simple XML file,
3. The controller instantiates the appropriate view and passes it the model,
4. The view transforms the model and sends the result to the HTTP response stream.

In my view the elegance of the solution is summed up by these features:
1. The content (aka the model), or XML file(s), are produced by OO programmers,
2. The designers produce the transforms (aka the view), or XSL file(s),
3. Steps 1 and 2 can occur in parallel as soon as the XML schema is defined,
4. There is NO script involved,
5. There is NO HTML hard coded or rendered in compiled code.

Despite the fact that I believe the front-controller & MVC approach are far superior to the page-controller one I intially found that it was taking me longer to get the applications up and running. I put this down to familiarity. At the start of the year, after working with the framework for 12 months or so, I did a test on how long it would take to build the IBuySpy site using Maverick.Net (implementation, workflow), it took 20 hours. I suspect this is not much different to the time it would take doing it using a traditional ASP.Net approach? However the big difference would be the maintenance. In the Maverick case all presentation can now safely be handed of to designers!

Regards,

aza

Coffeehouse - Are Web Controls an Anti-Pattern?

aza — Mon, 26 Apr 2004 08:44:51 GMT

If you are saying that the Web Controls should be replaced with XSLT I agree whole heartedly. This has the effect of moving the HTML out of code and into a stylesheet.

In this case replacing is really removing since the main function of the Web Controls is to produce the HTML. If you have the content XML then XSLT can be used instead of binding to a Web Control. I use ASP.Net without Web Controls.

I don't really see what you are referring to as the facade layer - perhaps System.Web.UI.Control - but in most cases it wouldn't make sense to get XML from it. For instance the XML for a checkbox or a textbox is fairly useless; it's the XML for the content that is going to be used in the checkbox or textbox that is useful. This content XML would be provided by another layer that is completely separate from the Web Control.

aza

Coffeehouse - Hows MS feel about Mono

aza — Mon, 26 Apr 2004 08:12:11 GMT

SMac wrote:

Very little people seem to get it.. the CLI itself is an ECMA standard. C# is an ECMA standard. this means you, your grandpappy, or academia can go out and build your own CLI yourself..

But certain parts of the base class library - which is what makes the whole thing useful - are not http://www.go-mono.com/faq.html#patents. The parts are ASP.Net, ADO.Net and Windows.Forms.

aza

Coffeehouse - Java and .Net Convergence

aza — Mon, 26 Apr 2004 07:52:42 GMT

sbc wrote:

Imagine writing a program that worked on Windows / Mac / Linux with changing the code (you would still need to recompile for the target platform though)

MSIL is platform agnostic. If you compile on a Mac to MSIL there is no reason why you shouldn't be able to use the same executable on Windows. Of course this is providing you stay away from pinvoke and OS specific portions of the library, i.e. Microsoft.Win32.

aza

Coffeehouse - Java and .Net Convergence

aza — Fri, 23 Apr 2004 07:55:32 GMT

For a lot of "professional" developers cross platform currently isn't a big issue. I have never been required to support any platforms other then Windows. I anticipate this changing in the medium term future as mobile platforms proliferate.

From the point of view of someone who earns their crusts from Window's development the best thing Java did was spur Microsoft into action to create a much better develpoment environment. I don't know if they would have created it anyway but regardless I think a lot of the Java learnings were leveraged.

What puzzles me a bit is the more open philospohy around .Net? Once mono ports .Net to Linux then in some cases Windows will lose its appeal. If Microsoft's thinking is that they'll create and guide a semi-open standard (like Sun and Java) and bank on the fact that they will be able to compete and win on building platforms then I for one think its commendable. And risky, it's going to be hard to go past a free combo of Apache and Mono ahead of a relatively expensive one like Win2003. I can't fathom the business value for Microsoft behind an open cross-platform .Net, although that could be part of the reason why I sit in a cube and not a glass paneled office with harbour views .

Relying on a closed environment, such as VB, to tie developers to a particular platform also probably explains the current fractures in the development community. Before .Net, as a developer you had to be for Windows, VB and ASP, or against it, Java. And since Java was a superior programming environment (maybe not execution but definitely programming) it attracted developers who then had to justify their choice. The most convenient way to do this was to disparage Windows which didn't really embrace Java. The broad generalisations are acknowledged.

.Net has appealed to developers (I don't have figures but I would bet there are more C# then VB6 projects in sourceforge not to mention the significant numbers of Java to C# ports) and if it becomes a robust cross platfrom environment then anti-Windows arguments become redundant and we can hopefully reach a state where the best tools for the job are chosen. Then we can get rid of platform and language religion, oh yeah and we can live together as one big happy software industry and talk about interesting things instead of "C# vs Java" and "Windows vs Linux".

aza

Coffeehouse - Are Web Controls an Anti-Pattern?

aza — Thu, 22 Apr 2004 12:26:06 GMT

As far as I am aware there is no option to render ASP.Net web controls as XML, HTML is the only option. The System.Web.UI.Page method that is responsible for displaying the controls is:

[C#]
public void RenderControl(
HtmlTextWriter writer
);

In most cases it wouldn't make a lot of sense to render controls as XML. What it would make sense to render as XML is the content.

I notice there is talk of Master Templates in VS 2005 I am hoping this will move towards ASP.Net using a front controller instead of a page controller, such as in Maverick.Net. This would facilitate a much cleaner separation in the web presentation layer.

aza

Coffeehouse - Are Web Controls an Anti-Pattern?

aza — Thu, 22 Apr 2004 08:14:06 GMT

Hi All,

No disrespect meant to anyone but ever since playing around with ASP.Net web controls I have a niggling feeling that something is not quite right. The feeling arises every time I come across HTML in compiled code.

Some points:
- Placing HTML in code can be difficult to change especially for non-programmer designers,
- Placing HTML in code prevents separation of the web application layers. The programmer becomes responsible for logic AND presentation,
- Using javascript to emulate the Windows forms event model in web pages can end up with a lot of toing and froing to the server,
- Windows forms apps and web apps are clearly distinct paradigms, at least to me, is convergence really possible? Will Windows forms apps using a web deployment model, e.g. ClickOnce, make web controls redundant?

Just some thoguhts,

aza