One of the first thing I did this morning was to make sure I had registered for the 2008 edition of the Pdc.
Any brits travelling to LA or any alt.net guys want to organize an unconf, let me know.
Now they need to open the registration for TechEd Europe and I'll be booked for the year.
I'm publishing this a bit late, but I took a few days (a whole two of them) without working. How refreshing!
In an effort for a more transparent process, here are a few things I think went well and didn't go too well. If you've been at the talk I would absolutely love your criticism. Practice makes perfection, but before that it makes for nicer presentations and a less worried Sebastien!
The font-sizes were all wrong in everything but the code-editor, this is quite unacceptable and certainly not like me at all. So be prepared if you install vs 2008 SP1 beta, it will reset all your settings. That explains the lack of proper configuration in visual studio. And of course, a problem never comes alone, vs refuses to start under my Presentation account that is set with ridiculously large DPI setting. But it all comes down to me installing this stuff too late, which left me no time to make sure everything was configured properly. Apologies to the audience, I should have had a VM up-and-ready with all my content. And apologies to myself for installing a beta service pack on my main development machines.
All the usual presentation tools were not installed on that laptop either, so no ZoomIt and no Keyboard Jedi. Again, with a reinstall of vista a couple of days before, I just didn't have the time to get it right.
One thing I find difficult is choosing a screen mode. When showing code, I want to show you my Visual studio and whatever other programs get spawned by it (ie, firefox, the command prompt) while still seeing them on my screen. For powerpoint, I want to keep presenter-specific stuff from your eyes (a timer, some notes, and in general the whole content of the slide you'll see appearing as I talk).
I need a hybrid between Clone and Span modes. I may have something working, so my next talk will guinea-pig the idea. I'll blog about it after trying it out. :)
Some people didn't completely see how the asp.net MVC and the REST part of the talk connected together, and maybe I should've introduced that at the beginning on the slides. But if you know me, I don't like slides and will avoid them at all costs.
This is the first talk I give where I put some content on slides, to refresh everyone on MVP and MVC and how the models differ. I like how visual it makes the explanation, but I'd rather manage to do it graphics only, with no text whatsoever. That requires more work, a tiny bit of animation and very good graphics. Nothing that can't be done with enough time for pimping it up.
I used the MacBook remote to change slides, and the freedom to move around to move slides is next to none. I also find that having the remote to hold from the tips of my fingers helps me avoid leaving my hands hanging. Hold something to keep your hands at chest level, it puts your body language into explanation mode. Relax and put one hand in your pocket and you switch to opinion mode.
Eye contact is the best tool to calm anxiety. You'll always find a couple of people in the audience being very expressive, that lets you judge the rhythm of the presentation. There's nothing worse than an expression-less audience.
I'm a bit in-between two waters on this one. The whole point of the talk was to see what toolkits you can use today to do REST applications, but, for various reasons, I fit in there an introduction to asp.net MVC as a first part. That just doesn't flow well, and I think I'll split those two in two different presentations: asp.net MVC introduction (I have some AJAX stuff to make that presentation complete), and REST today, rest tomorrow. They can both stand on their own feet, and it would leave me more time for doing what I prefer doing: talking rather than coding and rushing.
I tend to make jokes during the talk, they're usually completely spontaneous, but they fall flat every time, except for a few friendly grins from people I've met or talked to before. I shall prepare my jokes in advance and only use them after having tested them. But not on animals.
My voice level seems to be alright, but I speak too fast. And I have those pet words that creep in, amongst them "I think" (very annoying one I have a lot of problems getting rid of, even in day-to-day conversation), and Ok (very patronising, hate it, think I managed to mostly kick it off my presentations).
It's quite funny how the brain gives you those little fetish words. I think they creep-in because they trick your brain think there's a rhythm to what you're saying, when simple punctuation and sentences should be enough. It may also be the case that they give your brain enough time to reformulate when you're mid-sentence and unsure about what to say next. Again, preparation is the key.
This one bit me during the presentation. As I prepare the code for all the major steps, I end up with the same project at different stages, and I made the mistake of keeping all the projects in the same solution, often resulting in the wrong code being ran when pressing F5 and the wrong files being shown when I expected to show some code.
From now on, I'll keep all the projects in separate solutions.
I really like giving talks. It is a bit frustrating to come up with new material every time and only use it once, as you don't get the opportunity to retrofit what you learnt from presenting it once. Hopefully that will change as I get new speaking opportunities.
What:
With the raise of the web 2.0 meme, more and more web applications claim to support REST architectures. We'll explore together what is REST and what is not, and how we can write a testable web application that supports the REST concepts on the asp.net platform, with a code-intensive overview of current toolkits (asp.net MVC and others).
Where:
MRM Worldwide London
76 - 80 Southwark Street , Bankside Studios, London SE1 0PN
When:
Tomorrow Wednesday the 21st of May, 18:30
Why:
This, I have no idea of :)
That is, if I get Visual Studio 2008 SP1 installing properly on my demo laptop, which is no small feat in itself, or face a frantic rewrite of some of the presentation tomorrow.
Today is a day off, as I've accumulated 36 hours of work between Monday and Tuesday and needed some rest. The last project I've been working on has been one of the most interesting I've had in a long time, not only because I took more responsibilities than usual, being both a lead dev and as a scrum master, but because of the amount of technology we've fetched in one app. To give a quick run-down:
I've learnt quite a few things in the process, so here's a few reflections for my own benefits.
Overall, a very good project, a great team and a freedom that I don't have very often with clients. I think it'll be difficult to move to my next project, the comparison will suffer!
Got a message from Catriona, and the original location for our alt.net beers event was fully booked, so it's now around the corner from the previous location. See the original post for the details.
22:30 and still working on various bits and bobs, so I thought I'd take a well deserved break to tell you about one nice way to implement INotifyPropertyChanged, the one and only interface any class that will be bound in WPF should be implemented.
I used to (circa .net 2) not see a bit issue in this kind of code.
public class MyClass : INotifyPropertyChanged
{
private string _myValue;
public event PropertyChangedEventHandler PropertyChanged;
public string MyValue
{
get
{
return _myValue;
}
set
{
_myValue = value;
RaisePropertyChanged("MyValue");
}
}
protected void RaisePropertyChanged(string propertyName)
{
if (PropertyChanged != null)
PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
}
}
But I've been badly spoiled by automatic properties in C# 3.0, and this all sounds like a lot of noise. How great would it be if we could instead simply have the following.
public class MyDreamClass : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
public string MyValue { get; set; }
}
Definitly much cleaner. We're going to use DynamicProxy2, which is part of the Castle framework, and is used amongst other things in nhibernate.
The process is quite simple. You ask a ProxyGenerator to create a type for you, and pass it an interceptor object that will... Intercept any call!
First, let's clear up our class. Because the object generated by DP2 inherits from the original type, it needs to have a virtual modifier on the property. Furthermore, I wanted to add an attribute to specify which properties were to trigger the notification.
public class MyBetterClass : INotifyPropertyChanged
{
public event PropertyChangedEventHandler PropertyChanged;
[Notify]
public virtual string MyValue { get; private set; }
}
Now, let's see how we create the object.
static void Main(string[] args)
{
var proxy = new ProxyGenerator();
MyBetterClass myClass = proxy.CreateClassProxy<MyBetterClass>(new NotifyPropertyChangedInterceptor());
myClass.PropertyChanged += (src,prop) => Console.WriteLine(prop.PropertyName);
myClass.MyValue = "testValue";
}
Fairly simple so far. Now let's see the meat of the code, the interceptor.
public class NotifyAttribute : Attribute { }
public class NotifyPropertyChangedInterceptor : IInterceptor
{
public void Intercept(IInvocation invocation)
{
// let the original call go through first, so we can notify *after*
invocation.Proceed();
if (invocation.Method.Name.StartsWith("set_"))
{
string propertyName = invocation.Method.Name.Substring(4);
var pi = invocation.TargetType.GetProperty(propertyName);
// check that we have the attribute defined
if (Attribute.GetCustomAttribute(pi, typeof(NotifyAttribute)) == null)
return;
// get the field storing the delegate list that are stored by the event.
FieldInfo info = invocation.TargetType.GetFields(BindingFlags.Instance | BindingFlags.NonPublic)
.Where(f => f.FieldType == typeof(PropertyChangedEventHandler))
.FirstOrDefault();
if (info != null)
{
// get the value of the field
PropertyChangedEventHandler evHandler = info.GetValue(invocation.InvocationTarget) as PropertyChangedEventHandler;
// invoke the delegate if it's not null (aka empty)
if (evHandler != null)
evHandler.Invoke(invocation.TargetType, new PropertyChangedEventArgs(propertyName));
}
}
}
}
And that's it. Get the field in which the event is stored and invoke it whenever a property has been modified.
Just upgraded my development environment, here's the picture.
The laptop looks tiny next to the screen, but it is in fact a high res MacBook Pro, 1920x1200, driving as a secondary screen an Apple Cinema Display 30" for an added 2560 x 1600.
That's freakin' 6.4 megapixels of vista goodness! Surprisingly enough, Aero runs without a hitch.
Couple of other interesting points: new apple keyboard as I fell in love with the feel of the MBA keyboard, the mouse is not the one i usually have (but ran out of batteries). And Prada sunglasses for the one day of sun we've had in London so far.
As for drinks, the coffee mug is the property of the client at which I keep this equipment, and the can of Redbull kinda explains the name behind my company name: caffeine IT :)
In my Migrating to IIS7 post, I highlighted that building REST frameworks that do meaningful things with Urls is hard on microsoft's platforms.
I encourage you to go and read the comments left by Mike Volodarsky on the issue. He's a Program Manager at Microsoft. Having people from the team building IIS7 responding to people like me highlighting issues shows how some teams really engage proactively with their customers. Kudos!
The other team at Microsoft that understand REST a bit (and IMO the most out of all the teams working on this), is the Astoria team. And of course, because they do funky stuff with their URLs, they hit the same issues as me. So here's a link on how to deactivate some of the checks asp.net does. Nasty registry editing...
I really wish asp.net could recognize when an IHttpHandler does not want validation and let it handle the request, its validation and etc.
[Update: new location, see below]
Here's the latest development. The alt.net London Beers event is being moved!
Skills Matter is organizing a talk by Gojko Adzic on the Castle Framework on the day we originally planned for the drinks. As everybody has shown strong interest in attending both events, Skills Matter has been kind enough to help us organize the drinks in the Crown Pub in front of their office, so you can now attend both events.
Not only that, but they have also opened the possibility for another presentation on an alt.net subject, so if you feel like presenting, drop me a mail!
I have to thank Catriona at Skills Matter for sponsoring the alt.net London Beers event and inviting all the alt.netters to attend the Castle presentation, as well as Gojko for suggesting the merge of the two events.
So here's the recap:
We'll probably move back to the planned Tottenham Court Road location for our second meet, on the 16th of June. Keep your calendars open!
Lack of time and sleep pushes me to be very lazy and present only the most trivial example of what Rasta was built for. Hopefully the future editions will become more interesting.
Rasta does many things, but one of the things you can use it for is Url rewriting for webforms. Simply declare the following in your global.asax file:
using (RastaConfiguration.Manual)
{
UriSpace.HasTheUri("/home").ForThePage("~/pages/default.aspx");
}
And if you want to provide a url that matches a specific language, just expand this a bit:
UriSpace.HasTheUri("/accueil").InLanguage("fr").ForThePage("~/pages/default.aspx");
This will automatically set the language for the current request in the correct language, while still going to the same aspx.
Another fancy thing in Rasta's manual declaration is the using block. All the configuration needs to happen within that block, and is only applied when you exit the block. The fluent api is built using a chain of language elements that form a sentence. Each element you add to a sentence either replace it's predecessor in the list of sentences, or initiate a new sentence, and each fully-formed sentence will get called whenever the Dispose method is called on the object returned by the call to RastaConfiguration.Manual.
How do sentences get added? When you enter the block, the new object returned by the Manual property sets a CallContext that stores that list. When it is disposed, it calls the chain of sentences to configure itself. And finally, it makes most of the routing structures read-only to optimise them (a typical example is building a read-only tree of the Urls you can use for a site in a structure that is more efficient than if it was write-only).
That also means that trying to apply a configuration at runtime to replace the existing configuration will only succeed when the whole of the operation succeeds. This happens by only writing to a new copy of the configuration data, and committing the write if no exception happened. If you got the configuration wrong, the previous configuration will happily stay on to continue serving request.
Over the last couple of weeks I've been upgrading my Rasta framework to support IIS7. Here's the highlights:
I also ended up with some weird issues where upon building, the ccnet machine would see its access to web.config denied, and the only solution is to go and copy the files manually the first time around. I'm still trying to investigate what happened there.
If you're in London, why not join us tonight to celebrate Visual Studio 2008 and .net 3.5 releases at the London .net user group? We'll be discussing some of the new features in the bits, and I shall be presenting some useless code that shows integration testing and fluid database design using Linq2Sql, with some expression tree goodness.
[Update: The event has been moved. See the latest location and stuff here]
Many people are keen on continuing the discussion that was started by the alt.net conference. While the altdotnet-discuss yahoogroups mailing list has been very active, I feel that much more can be achieved when meeting and seeing people.
It's also nice to be surrounded by like-minded people that face the same challenges you do when you try to promote alt.net ideas around you, to your colleagues, your employer, your sister... And of course, being surrounded by very bright people that love what they do and spend their free time getting better at it is fantastic.
In the spirit of providing something less grandiose than a conference and more personal than a mailing list, I hereby declare created the Alt.net London Beers. It's an event, in a pub, with whoever wants to come, subject to be decided on the day. Bring your laptop if you want, but more than anything bring yourself, and let's get the conversation continuing.
This is an experimental regular meet-up, and who knows, if it's successful, we could do it a bit everywhere. Make this a success and come along!
Rasta has many meanings, but for the purpose of this blog, it is the REST Architecture Solution Targeting Asp.net. I've written this framework for one of my clients, and I'm in the process of trying to get the rights to open-source it and deliver it to the world. But as many things, it takes a lot of time.
That said, I've been wanting to blog about it since I started working on it, so now is as good a time as ever to start showing some bits on how to use it. It will let my beloved readers criticize the way the API is built, which will let me involve it for the better, and will also serve as a reference point for my client's employees to have some sort of reference on how the framework works.
Rasta, in essence, is a framework that lets you think about your site in terms of resources, how they are accessed, and how representations of such resources get served to clients. Let's compare this approach with other approaches we've seen over the years.
In this model, your Url is bound to your page. Because of the post-back model, any interaction with the system is done as units within the webform. http://example.org/Customer.aspx provides a view of your customer, but is also where data gets posted back. The posting of the data itself can be either about a customer, or about a button, or about an event one of the webcontrols can trigger. It can be a bit of anything.
This has a couple of very bad consequences. Only the asp.net framework can post data to /customer.aspx, because it's the only one knowing the format. This makes testing webforms terribly difficult, and patterns like MVP only solve the problem at the unit-testing code level, leaving a lot of code non-testable. It also makes integrating with other systems more painful than it should be. And it doesn't leverage hypertext in any way, because state is transferred across postbacks through either the session or the viewstate.
In this model, the resource is the page, and does many things. It's completely unrestful.
A lot of noise is being made about the new asp.net MVC framework. MVC as a pattern solves some of the issues introduced by webforms. Your Url is bound to a controller that receives the request, act upon it and send you to a view based on the result of the operation. This solves the unit-testing issue. To a certain extent, it also solves partially the integration issue, as your controller can act upon the http operations (GET PUT POST DELETE etc...).
That said, your Url is bound to a controller's action, so you would end up most of the time with a url looking like http://example.org/Customer/GetCustomer. You're mapping one web action to an operation. While you can override that, it's not the default. Another issue that makes it unrestful is the lack of leverage of hypertext, as links are not used for anything meaningful unless you implement that yourself.
In this model, the resource is the controller, and does quite a few things. It's up to you to define the semantics. It's quite unrestful.
WCF in 3.5 has some support for something quite similar to the model provided by MVC. Your WCF service can be mapped to a specific Url and encoding (xml and json), and it will support a Get and a notion that team came up, an invoke. The rationale being that there was not that much of a different meaning between POST/PUT to justify mapping them differently, and that they all end up invoking a service.
This is a service-centric view that maps very poorly with the web. You're tying your Url to a service operation, and limit your representations to the two kinds provided by WCF. Its great for unit testing, not so much for the web.
I'll also have to question any team having spent that many years providing an abstracted toolkit that lets you not think about the plumbing (although this is a very big white lie) trying to implement a REST architecture which is, by definition, about the plumbing, leveraging Http verbs and hypertext.
In this model, the resource is the service, and does something. It's quite unrestful as well.
Formerly called Astoria, ado.net data services is the most restful of the APIs Microsoft is working on.
With Astoria, you map a Url to an entity (ado.net entities), and you interact with those entities based on AtomPub, which is quite restful. That said, it is about exposing your existing entities model on the web, and support for POX / POJson has been dropped from what I understand.
It does leverage hypertext (because AtomPub does), and it does have some content type negotiation. The big issue here is that it doesn't integrate with any of the previous models we've seen, and is yet another API that wants to have the Urls in your web application to itself. It supports data, and data only, so you won't be able to leverage an asp.net MVC page to serve a resource as text/html, and still support application/json for clients that want this format.
In this model, the resource is the entity, and you can do restful things with it. But it only deals with one aspect of developing rest applications, and has poor integration with the other components Microsoft is developing.
Rasta takes a radically different approach. Every Url is mapped to a resource. In other words, http://example.org/Customer is mapped to a resource of type CustomerEntity. Each resource type can have many resource handlers that are responsible for acting upon a resource in a certain way. This could mean retrieving a resource, updating it, etc.
When you access a Url to get to a resource (called dereferencing), the first step Rasta is going to take is to try and locate which handler can be used to access the resource, based on the request you made. For example, http://example.org/Customers/{name} is a Url that would associate a meaning of name with a value to the handler. From that name, the handler would return an instance of the resource (an instance of CustomerEntity). In other words, a handler is responsible for dereferencing a Uri based on a request to get to a resource, and to act upon it if required.
And that's it. The handler is not involved at any point in how the request is processed or how the response is sent to the client. This is the responsibility of the codecs.
A codec is a component that, to simplify, convert a Content-Type sent on the wire to an object and back. In essence, if your handler returns an instance of CustomerEntity, the codec will be able to convert it into an xml stream representation, or whatever wire format the codec supports. Out of the box, the current Rasta svn repository has support for webforms (for html rendering), json and xml, and I have some working code supporting AtomPub, atom, rss and even support for some WebDav, although all this is mostly prototype quality.
In this model, the resource is the resource, and its representations are handled by codecs that are loosely coupled from the resource itself. You could see it as an application of the semantic web, but based on types and objects. In other words, it works and is good enough.
Rasta's architecture brings quite a few benefits:
There are many other parts to Rasta, but those are the basis of what it is, why it was built, and why I'm so thrilled about it.
Going to the dentist is an awkward experience. You know you have to use their service or your teeth will rot, but the experience is just not enjoyable.
That's how I feel about string.Format. I use it all over the place, but find it incredibly out of place. Thanks to extension methods though, I can propose a nicer syntax. Here's a snippet from a site I'm building for one of my clients, using my rasta REST framework and linq2sql.
[HttpOperation(HttpMethod.GET, ContentType=new HttpContentType("image/*"))]
public ResourceOperationResult GetMovie(string filmName)
{
var movie = _movies.FindOne(movie => movie.UrlTitle == filmName);
if (movie == null)
throw new ResourceNotFoundException
{
Message = "The movie {0} wasn't found in the database.".With(filmName)
};
return new ResourceMovedTemporarilyResult { NewResourceUrl="/library/tempfilm.jpg" };
}
Notice the extension method there? I just find it sweet. Here's the very simple extension method.
public static string With(this string text, params object[] values)
{
return string.Format(text, values);
}
There you are, a shamefully simple extension method, just because I can!
While looking around for nice visual studio color schemes, I stumbled upon Commonality's Naming your computers post. I'm happy to know I'm not the only one doing that.
All the computers in Caffeine IT are named on the theme of light. Here's a rundown.
And before you ask, of course I need that many. :)
You know you're starting to be read too much when people get passionate about name-calling you. I'm very proud it is now happening to me, as Anonymous has proved in the first aggressive comment I've had on this blog.
That said, Anonymous said the sub-title of this blog should be renamed to Ramblings of a self-congratulatory, self-proclaimed, egotistical doofus.
So this is now my new tag line. Whatever you think of me, you're reading, so that's a communication channel open. If you disagree with me I'll probably learn something from you. If you agree I'm pleased I am not on my own in my rambling.
We're all on a journey. I'm pleased mine involves anonymous and prominent people questioning my opinions. It makes me a better geek, and that is what this blog is all about.
Just found some referrals from wikis used internally at a previous client, full with the reference of the page, project code-name, etc.
I wonder if anyone realizes how much information you're disclosing by just linking...
[Update: Removed references to the company, because while I may rightfully be bitter, it is irrelevant to the content of this post, and I don't want the two issues to be mixed. Apologies to my readers.]
Jason Gorman, who I've had the pleasure of crossing the path of at one of my clients, is asking an interesting question about containers: are we hiding sweeping dependencies under the carpet?
Questioning the value of a container is a very recurring topic amongst developers that haven't been ripping their benefits, and I think it deserves a post in its own (that, and the fact that Jason's blog doesn't seem to let me post comments.)
First comes first, you have to think about what a container brings you, as it does bring you several things.
Dependency injection
This relieves you of having to chain objects that depend on each others, as the container is responsible to get a reference to each component your component needs.
This has the added benefit of enforcing the declaration of your dependencies in the component's constructor, making tracing dependencies much easier in a code review. It's also a good thing for discoverability of the code during test, as knowing what is required for your component to be put under test is very much in your face, on the first line, when you create the object. And that is a good thing.
Inversion of control
Your code no longer has to create the object to use it. You just don't have to think about it when you write your code. Of course, that doesn't mean you can ignore how the object is built, but this enforces a separation of concern: the consumer of the object doesn't have to know a whole lot to consume, and the creator of the object doesn't have to know much about the use of the object.
Lifetime management
Because you no longer use new, you can rely on the container to decide which object it gives you and where it exists. That means that asking for an IMyAppContext will retrieve the object from the HttpContext for you when it's needed, with no HttpModule or painful initialisation code anywhere.
And if you work on composite applications, you can create for the container a new way to store the objects, be it per component, per form, etc. You write that code once for the container, and never again will you have to care about the how.
Code reuse is a good thing.
Centralized component management
This one is less obvious but makes a lot of sense. When you want to know how an object is initialised and where, it's centralized in one place. One file gives you all the dependencies that exist in the system.
This also makes it possible to run code in your integration tests (or as a post deployment task) to ensure all dependencies are resolvable, and this, again, is a good thing.
Lower the cost of change
This one becomes obvious when you've been using containers for a few iterations. Taking on a new dependency is fantastically easy: add a parameter to the constructor and you are done. No consumer will ever have any code to change. Less code to change makes me happy.
There are many other things a container can do, but those points are shared across Unity, StructureMap and Windsor (I specifically ignore spring.net in my analysis, because I have next to none experience with it), and even by the COM+ catalog.
Jason probably knows each of those points very well. His doubts are about the centralized place in which those components are declared.
To a certain extent, I will agree on a small thing. Storing your dependencies in an xml document is not the most natural way to handle them, especially when you start playing with generics.
In the project I worked for in that unnamed media company, I built a small object builder as I was asked not to take more dependencies on external frameworks, hence I couldn't rely on a container. The dependencies were stored in the config file, and object instantiation is manual (no DI there, just IoC). A super-factory was a good first step to start decoupling components and get more visibility on what was going on in the code. But it's not as nice as having DI, and certainly not nice having types written in xml.
But you don't have to keep these things in config files. If you want to keep your dependencies as part of your project's code, go for it. Windsor has AddComponent, SturctureMap a fabulous Fluent api.
And if you don't want writing all that code, you can use Binsor for some boo love.
What I will strongly disagree with is part of Jason's analysis. A container doesn't hide dependencies from the compiler, because it can't. Component A implements interface A in assembly A. Component B depends on interface A and lives in assembly B. As far as I understand it, they all get compiled by a compiler. They are linked so dependencies are resolved when compiling the construction. That's why you declare your dependencies in the constructor!
But where Jason is right is highlighting that the configuration file is a dependency, and should be tested as such. This is exactly why you should have a stage environment that reproduce your live environment, and run your integration tests there. If your test don't detect a missing dependency declared in your config file, your tests are badly written or not extensive enough. You're just blaming the tool, blame the developer.
One thing that seems to be a common misconception is that you should know about your physical dependencies, aka knowing that component A depends on component B. This is the wrong way to look at the problem. Component B should depend on a contract it has for a service it's being provided. The glue between components is the container, and the guarantee that this works fine is your test. As for understanding your dependency graph, that's what code coverage and NDepends are there for. Anything else is only relevant to graphs people want to put in visio, which I would argue is irrelevant.
That said, it wouldn't take much work to trace those dependencies by asking the container. Maybe a day of work if you're into graphs. But if your dependencies bite you, you have a much bigger problem than tracing graphs, and that's usually a collapse in applying what is required for containers to work well: contracts, single responsibility principle, high cyclomatic complexity, poor code coverage, no integration tests, and self-containment of components to reduce complex interactions...