Geeks With Blogs
Braulio Díez Botella blog

 

Maybe this can sound you a bit obvious, but it’s something that I have found in several teams / projects, and I think it’s worth to point it out.

When you start your own project as a solo developer, or build a small team to work together it’s quite common to agree on downloading the latest version of the Silverlight toolkit and install it… so far so good, everybody is compiling the application and able to work with the source code, … after some weeks you start having issues:

  • Some developers decided to install a more recent version of the toolkit, current source code version need some fixes in order to compile… when developers deploy that fixes, other users get problems when trying to compile the code with the older version.
  • New colleagues join into the group, they need to know which exact version to install from the toolkit (installing the latest… means maybe code won’t compile).
  • If you are an open source developers, your code will be downloaded by other users that maybe even don’t have the toolkit installed… so they will try to compile your samples check that they get compiling errors and stop digging into your project (no time to loose).
  • Sometimes you are working on more than on project, and not all of them are referencing the same version of the toolkit.

What can I do to avoid this issues? Well… the solution is pretty easy:

  • Create a lib file in your source code repository and include there the DLL’s of the toolkit that you are using.

image

  • Reference that DLL’s in your project (include it just browsing for them and choosing the DLL’s).

image

By doing this:

  • Users won’t have to install certain toolkit version their machine to compile your code.
  • You won’t have to rely on developers having one exact version of the toolkit installed (this references will be read from the lib folder that you have defined).
  • If you upgrade your project to use a newer version of the toolkit you will only need to copy the new versions DLL in the lib folder, refresh references and ask your developers to make a get latest version.
  • You can build projects that uses different versions of the toolkit, each project will read the right DLL version from the lib folder.
Posted on Sunday, January 31, 2010 12:58 PM | Back to top


Comments on this post: Avoid Silverlight toolkit DLL hell

# re: Avoid Silverlight toolkit DLL hell
Requesting Gravatar...
I agree. This approach must be used in every projects. But I'm so upset that it doesn't work in Visual Studio 2010. The IDE will look for libraries on the project start-up and if you have installed Toolkit in Program Files then VS will take files from there.
Left by tearaway_Tea on Jan 31, 2010 8:56 PM

# re: Avoid Silverlight toolkit DLL hell
Requesting Gravatar...
Yes you are right, I think in VS 2008 it has that default behaviour. I remember in a project we were thinking why a doing a get latest in some machines they got the installed version of the toolkit instead of the lib one.

I would say... then if you have problemas because of that uninstall the toolkit.

I will research a bit more on that issue, makes no sense, it should be the other way around... if there is no lib toolkit library try to find it in the system.

Cheers
Braulio
Left by Braulio on Jan 31, 2010 9:21 PM

# re: Avoid Silverlight toolkit DLL hell
Requesting Gravatar...
Why does VS even look it from system is you explicitly specify where to look for it?

In our enviroments every external assembly is part of the solution structure under our source control. This makes life easier for everyone as you only have to do get latest to get a compilibable solution.
Left by Pekka on Feb 04, 2010 5:41 PM

# re: Avoid Silverlight toolkit DLL hell
Requesting Gravatar...
I totally agree with the frustration expressed here! This is a terrible "feature"! I did find that by setting a "Reference Path" in the project I could force the project to find my toolkit assemblies in my "lib" folder instead of at the installation location. However, the reference paths are stored in the .csproj.user file and don't seem to support relative paths...
Left by James on Apr 15, 2010 7:34 PM

Your comment:
 (will show your gravatar)


Copyright © Braulio Díez Botella | Powered by: GeeksWithBlogs.net