Question about Visual Studio 2005, Bin folder, project references, and source control

[clintonb]

I'm a newbie when it comes to asp.net. All my prior experience is in
making Windows applications in C++.

In the past when I made windows applications, the project or target
file would keep track of the dlls that are required by the project.
This project file would then be checked into source control. So if
another user got the project from source control, they would also know
which dlls are required by the project.

In ASP.net, it appears that there is no file that keeps track of the
dlls that are required by a project. I have a third-party dll that our
website uses. So to make the project compile, I have to add a file
reference to the dll; when I do that, the dll is copied to the bin
folder of my project. But I keep reading that you should not check the
contents of the bin folder into source control. So if another user got
the project from source control, they would have no idea which dlls are
required by the project. I think that sucks (for lack of a better
term). Or am I missing something?

Thanks,
- Clint

 

[Cowboy \(Gregory A. Beamer\)]

In ASP.NET 2.0, the .refresh files in the /bin folder track required DLLs.
It is designed this way so you have a folder based web in addition to an IIS
web. It makes things easier in some respects, but can be a pain in the rear
in others.

 

[Guest]

Try adding the 3rd party assemblies into the Solution as Solution Items (you
could have a SolutionItems folder if you want. Do this with the Solution
checked out.
Then, check everything in.
When another developer gets "Latest" on the Solution, your SolutionItems
folder comes with it and they can find the dlls. easily.

If you need to update a dll, check it out, overwrite with the newer one, and
check it back in.
Peter

 

[clintonb]

Thanks for the response.
Unfortunately, I don't see any .refresh files in my bin folder.

- Clint

 

[clintonb]

Peter, thanks for the response.

I've always been reluctant to check compiled code into source control.
I figured source control was only for source code, not compiled code
such as dlls and exes. In fact, I thought that was the reason for not
checking in your bin folder contents.

With your plan, you are checking dlls into source control, although
they are listed as solution items instead of files in the bin folder.
Why is your plan better than just simply checking in the bin folder
contents? In both methods, you are checking dlls into source control.
Is there some other reason why you shouldn't check in the contents of
your bin folder?

Thanks,
-Clint

 

[Guest]

Try checking in the /bin folder and see what happens during a build when all
your read - only dlls that you forgot to check out are locked.
Cheers,
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com