This is really shocking (and very disappointing) to me.

I had the task of upgrading the code base at Walsh Construction from .net 1.1 to 2.0 and putting it all in a source control database.

I had been getting a lot of totally random build problems, and I started wondering: Where does it store my references?

ASP.Net Web Sites projects don’t have a vbproj or csproj file anymore, so where is it storing the fact that I want this website to have a references to a given DLL or a given project in my solution?

I found that the answer is that the project references are stored in the solution file! 

If you open up the solution file you will find lots of stuff like this:

ProjectSection(WebsiteProperties) = preProject
ProjectReferences = "{E050AEA3-6DCA-4DE8-936F-5A8B14A912B9}|MyReferencedAssembly.dll;

This is kinda stupid.

Non-website projects keep a list of their references in their project file.

Websites keep SOME reference info in their web.config, although I think that is only for DLLs that are in the GAC.

Anyway on to the list of things that truly suck about how this works:

1)  When you add a reference from a web project to a DLL, the DLL is copied to the Bin directory right then, as opposed to when you do the build.  I bet it does it at build-time as well, but what really sucks is that you can have a situation where WebSiteA references ComponentA which references DataAccessLayerA.  WebSiteA will have DataAccessLayerA.dll in it’s bin directory, then if you go to add a references from WebSiteA to DataAccessLayerA, it will say “Oh you already have a reference” when you really don’t, and if you try to build it won’t work until you go delete that dll from your bin and add the reference.

2)  I have been unable to open some projects without opening the entire solution that I joined them too at one point.  Basically as I was converting all our projects over to 2003 I wanted to also change them from DLL references to project references.  So I created a solution with ever project and website we have in .net.  To illustrate my problem, I added a project to the solution called IAmABogusProject with 1 class and 1 static method.  No one uses this class, no projects have a reference to this project, and this project has no references to any other projects.  Yet, if I go click on the vbproj file for this project, it loads up my solution file with every single project.  I tried creating another solution and adding it to that one to see if it would open the new solution when I tried to reopen the project but no luck, it opened original solution with every application again!! WTF!!

3) This is the worst of the list.  If you have a project in a solution that is referenced by some other projects and you remove that project from the solution, guess what happens?  In 2003 it would remove the project and all the referencing projects would show a missing reference icon.  In 2005 it checks out all the referencing projects and removes the reference!!!  Are you kidding me???  For the cherry on top, you have to then manually add all the references back after you add the project back into the solution, and of course you get all kinds of weird bugs, none telling you that you are missing an assembly reference.  Totally stupid.   This is a bug, see Update3 at the bottom.

I am really pissed about this.  Why do MS product upgrades frequently come with a “What were they thinking?” tag? 

Maybe the roll of the solution has changed or something, but this is going to really piss me off working like this day to day.

I have already had something happen where all my website projects that I had already added to source control lost their binding.  Great….

Update1:  I am continuing to have problems with my web project “losing” references that I have to keep setting.  What a pain this is becoming!

Update3: Well thank God, someone from Microsoft let me know that this thing with removing a project causing references to disappear is actually a bug: http://www.chrismay.org/2006/04/19/VS2005RemoveProjectLoseReference.aspx 

Brian Noyes is the guest on DNR TV to cover databinding in .Net 2.0.

The video can bee seen here.

Here is the link to get the book in beta:
http://www.apress.com/book/bookDisplay.html?bID=10090

Expert VB 2005 Business Objects takes you from an opening discussion of logical architectures to detailed n-tier deployment options using the CSLA .NET Framework. Rockford provides enough understanding and detail for you to take this approach to your own projects, as many developers have already done.

I had always had issue with implementing ICloneable in the .Net Framework on my classes.  Implementing ICloneable requires that you return an Object, but a lot of time you don’t want to return an Object type, you want to return a strongly typed object of type whatever.

Well, thanks to a tip I heard on .NetRocks from Rocky Lhotka, I have coded up an example of how you can a) Implement ICloneable, and b) return a strongly typed object from your Clone method.

Imports System

Public Class BusinessObject
    Implements ICloneable

    Private Function privateClone() As Object Implements ICloneable.Clone
        Dim MyClone As Object = makeClone()
        Return MyClone
    End Function

    Public Function Clone() As BusinessObject
        Dim MyClone As BusinessObject = makeClone()
        Return MyClone
    End Function

    Private Function makeClone() As BusinessObject
        '*** do the clone here
    End Function

End Class

The trick is to implement ICloneable as a private function.  To be honest I have no idea why this works.  You would think that implementing the Clone method as a private function would mean that you couldn’t access it, but as the code I wrote below shows, it does work.

imports Microsoft.VisualBasic
imports System
imports System.Collections

public module MyModule
    sub Main
        RL()
        dim o as new BusinessObject
        WL("IClone " & o.Clone.IClone)
        WL("StandardClone " & o.Clone.StandardClone)
        dim i as System.ICloneable 
        i = ctype(o, System.ICloneable)
        WL("IClone " & ctype(i.Clone,BusinessObject).IClone)
        WL("StandardClone " & ctype(i.Clone,BusinessObject).StandardClone)
        RL()
    end sub

    #region "Helper methods"

    sub WL(text as object)
        Console.WriteLine(text)
    end sub

    sub WL(text as object, paramarray args as object())
        Console.WriteLine(text.ToString(), args)
    end sub
        
    sub RL()
        Console.ReadLine()
    end sub
    
    sub Break() 
        System.Diagnostics.Debugger.Break()
    end sub

    #end region

end module


public Class BusinessObject
    Implements System.ICloneable
    public IClone as string = ""
    public StandardClone as string = ""

    Private Function privateClone() As Object Implements ICloneable.Clone
        Dim MyClone As Object = makeClone()
        ctype(MyClone,BusinessObject).IClone = "true"
        Return MyClone
    End Function

    Public Function Clone() As BusinessObject
        Dim MyClone As BusinessObject = makeClone()
        MyClone.StandardClone = "true"
        Return MyClone
    End Function

    Private Function makeClone() As BusinessObject
        '*** do the clone here
        return new BusinessObject
    End Function

End Class

I will have to get to the bottom of this private thing.  But at least this will work and do you want expect it to.

Update: I got some answers from a couple people online.
Alvin Bruney (http://msmvps.com/blogs/Alvin/ ) suggested:

This I knew, but I guess I was wondering why the compiler allows you to do this.  I guess it makes sense that the interface makes that method public, so public it is!   Case closed