Re: HELP!! I'm having "DLL Hell" in .NET
From: malcolm (chakachimp_at_yahoo.com)
Date: 02/08/04
- Next message: Paul M.: "Clients network login"
- Previous message: Gordon Knote: ".net remoting question"
- Messages sorted by: [ date ] [ thread ]
Date: 8 Feb 2004 00:25:47 -0800
Ahhhh!
Finally, we got everything working. The problem was we were trying to
get too cute. Here is a list of problems we were doing wrong which
compounded our problems, so if you're having similar problems please
advise:
1) Use the default Build Paths Microsoft provides in each of your
projects. This is extremely important and in fact, Microsoft has a
huge known bug if you don't do this (and your dlls are larger than
64kb). Check out this article for more details:
http://support.microsoft.com/?id=313512. We were getting bit by this
one big time.
2) Very related to #1, leave CopyLocal = true for all referenced
projects.
3) All references should be done by project rather than by dll (unless
of course it is a 3rd party dll). This yields several advantages and
has no down sides (that I know of). One of the biggest advantages is
that Visual Studio can determine your build order.
4) What this allows you to do is basically have every project open in
1 solution. Then, Visual Studio will figure out what needs to be
compiled and when. This is a movement away from the way I remember
teams developing in COM. In otherwords, the dlls are now arbitrary and
the heart of everything is the code.
chakachimp@yahoo.com (malcolm) wrote in message news:<4fe7c9e8.0401211027.2f07e5c3@posting.google.com>...
> Hello,
>
> We have a small team building a project that involves some 30 or so c#
> assembly dlls. It is a client server application with 1 exe as the
> starting point. The dlls and exe are sharing an assemblyinfo file that
> has a strong name and version assiciated with it. We are having
> problems in the way we have been developing. We have made two attempts
> at this.
>
> Attempt 1) In our first attempt, we basically had 1 folder that
> contained all the output assemblies. This used to be the way we did
> things in COM, but this causes us to have to re-compile every
> dependant project when we make changes. I thought .NET was supposed to
> solve this? On top of this, every dll get's locked by Visual Studio.
> This means it becomes difficult to open more than one Visual Studio
> project at once (another thing we used to do frequently in COM with no
> problems). We had all "copy local = false" set for all references
> since they all pointed to one output directory. We even tried
> variations of the copy local settings depending on whether the project
> was the starting main exe or a referenced assembly. We just couldn't
> get it right so we did some research on the web and switched to
> Attempt 2.
>
> Attempt 2) Now we have each assembly pointing to it's own output
> directory in a hierarchy format. The exe is the root directory with
> all the supporting assemblies in directories in the root. We have
> been very conscious that the reference paths are all in the corect
> order to make sure the correct asssemblies are being referenced. This
> means that each assembly has (in it's output folder) a copy of the
> assemblies it needs. This is accomplished because we set copy local =
> true for each reference in these assemblies. The exception is the main
> executable. In here we have all the assembly references set to copy
> local = false. We found this approach on the web and it seemed that
> this was the nirvana we were seeking. But the reality is that we were
> still having problems. We cannot compile any core assembly without
> having to re-complile every dll that references it. In COM, there was
> the concept of binary compatibility which allowed us to compile core
> dlls as long as it didn't break the Interface (i.e. we could do
> internal changes and/or add methods and properties). I'm thinking .NET
> should be at least this good if not better. On top of this, we now
> have to manage our reference paths hiarchy. Since the main executable
> points to each output folder, the order of the reference paths is
> crucial since core dlls show up several times (from the perspective of
> the main exe). We are also very consious of the project build order
> settings which are set correctly.
>
> So in short, both methods yield COM like results (if not worse). And
> many times we won't find the errors until run-time which is even
> worse. We'll get assembly IO errors due to assembly manifests
> version's not matching. We also occasionally get dll locking issues
> caused by a number of reasons such as User Controls and having
> multiple Visual Studio's open.
>
> I'm convinced that there is a correct way to do this. Is there a 3rd
> way that we should be developing or is one of our first two attempts
> close but not exactly right?
>
> Any help would be greatly appreciated.
>
> Thanks,
> Dave
- Next message: Paul M.: "Clients network login"
- Previous message: Gordon Knote: ".net remoting question"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
