I’m working on a fairly complex Silverlight application (Entity Framework 4, Prism/Unity, WCF RIA Services) and suddenly ran head-first into a need for some object mapping. I haven’t done this before, but I had heard of Automapper so I Googled it and read the documentation. Perfect!
Then I read up on the Silverlight Automapper release. Uh-oh… last built in February 2010. For Silverlight 3. Curses…
I had two options at this point. Do my mapping at the server side using the “regular” Automapper, or dig in and make Automapper Silverlight Edition work for me. I downloaded the source, thinking I could (as I had done before with other projects) simply change the compilation target to Silverlight 4 and recompile. Tried this and BAM! No worky. The version of mscorlib is 2.0.
Tried removing mscorlib and re-adding it from the Reference Assemblies. BAM! Visual Studio bug.
OK, so this will have to be a new project:
- File-New Project/New Silverlight Application. Call it Automapper.Silverlight4.
- Copy the “lib” folder from the Automapper source into the root folder of your new build
- Add Reference to Castle.Core and Castle.DynamicProxy2 from the lib folder (don’t worry about the net3.5 folder, still works)
- Right-click the project and select Add Existing Item
- Navigate to the Automapper source and select all files in the root, then select Add As Link from the dropdown.
- Create Internal and Mappers folders and repeat the above steps for those folders in the Automapper source project.
- Delete links to DataReaderMapper and ListSourceMapper under Mappers folder (not supported by Silverlight.)
It works! I now have Automapper working in a Silverlight 4 application. I’m sure I’m not the first to try this, but it’s good to know it’s possible.
I’ve been quiet for a while because I’ve been working on a pet project: VSTime. It’s finally ready to try out and is available at http://vstime.codeplex.com.
What it Does
VSTime is a simple little Visual Studio plugin that records events such as file opening, compiling, and debugging. It tallies up all that time spent doing those individual things and presents a report. You can see how much time you spent editing files, building, and debugging, and a total time spent on a solution.
I hope that this utility will be useful to developers in measuring the time you spend actually doing the rubber-to-road work of development. I hope no pointy-haired managers get it in their heads that this tool can or should be used to measure productivity. It can’t and won’t, so don’t try.
However, if your pointy-haired manager insists that a 386 with 256MB of RAM should be plenty, don’t be shy about showing him/her how most of your time is spent building/compiling your projects. Graphs like the one in VSTime could be very effective that way!
I agonized over some of the design decisions, most especially the method for persisting the event records. I finally settled on SQL Server 2005 Express for two primary reasons:
1. If you have Visual Studio 2008 installed, SQL Server 2005 Express is installed by default.
2. The row_number function in SQL 2005 makes tallying the time of each event rather easy.
VSTime is designed in a way that should make it easy to plug in a different persistence layer. I may develop a SQL Compact or SQLite-based DAL plugin in the future.
VSTime takes advantage of the EnvDTE.DTE interface, which is the wrapped COM interface that represents the Visual Studio IDE automation object model. EnvDTE.DTE exposes an Events interface, which in turn exposes a bundle of interesting events, including Solution, Window, Build, and Debug -related events.
How It Works
Each of the events, including file open, build, debug, and a few others, is recorded to an EventRecord table. The duration of an event is the time it occurs to the time the next event is recorded. So, for example, if a file is opened at 12:00.00 and then the project is built at 12:05.00, then that file has been “active” for five minutes. The action of the next event “ends” the current event. If the user then goes back to the file, the WindowActivated event is registered and time begins to accrue on that file again.
If you walk away from your desk for a break, an idle counter kicks off after five minutes of no activity. This records an IDLE event, and the duration of IDLE events are filtered out in the reporting. If you are editing a file, a keyboard event resets the counter each time you hit the Enter key. The idle timer is hardcoded at the moment. I have set up a work item to make it configurable.
You can view the time spent on the currently-opened solution by selecting Tools-VSTime. Like the little stopwatch in the menu? It’s the extent of my artistic ability :)
The first tab of the VSTime ToolWindow displays a grid of the time spent on each activity, in descending order. Based on my experience, you will likely find a file or two (or more) at the top that contains all the important stuff, with lesser files, debugging, and building further down. This of course will depend on your usage patterns and the nature of your projects.
The second tab displays a horizontal graph of all the events. You can zoom in on the events by drag-selecting an area of the graph. Zoom back out by clicking the little button above the scrollbar.
The VSTime database is very simple. There are two tables: Solution and EventRecord. Each EventRecord relates to a Solution. As explained above, Event duration is defined as the moment an event occurs to the to moment of the subsequent event. I believe this is effective, but there are some issues.
The primary issue to be aware of is that it is possible to edit a file while debugging in Visual Studio. This means that you could be, in practical terms, “Debugging” and editing a file at the same time. The Solution Total Time will still be accurate, because the act of activating a file window will “end” the debugging event. However, VSTime does not currently support the idea of concurrent events, so your event time tallies for Debugging may be off if you often edit files while debugging.
Support for VS 2010 is planned and will be in the next release. I don’t think I’ll be spending any time on VS 2005 compatibility, but if there is tons of interest I may reconsider. Future releases will include more tests. I’m also looking into the possiblity of tracking additional interesting events such as source control commits.
Yes, It’s Open Source
Please try out VSTime if you think you’ll find it useful. If you love it/like it/hate it, don’t be shy. Post here or on Codeplex. Tell the world what you like/hate about it. If you’re really passionate about it either way, get involved and make suggestions or even post a patch!
As I was doing some work on my VSTime project I realized that my favorite source control tools might be of interest, so here they are:
TortoiseSVN integrates directly into Windows Explorer and turns any old folder into a Subversion-controlled repository. Free to all.
AnkhSVN is an open-source plugin for Visual Studio that connects to Subversion repositories. Again, free.
This is by far the coolest of the bunch, though you need the first two to use it. Codespaces.com is a Subversion host, and much more. It’s not free, but $2.99/month is a very good deal for:
- Multiple Users
- Work Items
- Card Wall
- Document Repository
- As many code repositories as you have space for ($2.99/month buys 500MB)
- Project Portal (you can share details about the project with outside stakeholders)
I’ve been using the service for several months and it’s awesome. Very good for personal projects you want to keep backed up, especially if you work on multiple machines.
One caveat: if you set up these tools, don’t attempt to manage Visual Studio project checkins/checkouts through TortoiseSVN, use only AnkhSVN. There’s some versioning issue between them, so if you try to use both on the same project you may end up with a versioning error. Just stick to using AnkhSVN and you’ll be good to go. This may have been addressed with the last release of AnkhSVN, but I haven’t tried it.