Problems with bin folder and .dll files

[eday69]

We have Vault sort of working, but we have to jump through a bunch of steps to get our server to see changes to our files. Here is the process we have to go through using Visual Studio 2005 sp1.

We check out files on our local machines, make changes, build them and test them locally.

If everything works, we have to check out our recreationapplication.dll file from the bin folder, build locally, then check in all files to the server.

If we don't check out the recreationapplication.dll file from the bin folder, the changes do not get uploaded to the live server.

When we go back to our local machine and check out more files, make changes, and try to build we get an error:
Unable to copy file "obj\Debug\RecreationApplication.dll" to "bin\RecreationApplication.dll". Access to the path 'bin\RecreationApplication.dll' is denied.

We then have to copy the bin folder from the server to our local machines, then build to get a successful build.


While this works, it doesn't seem like we should have to copy the bin directory locally every time we check in files from the server. This is the only way we have been able to get changes to show up on the live server.

Please let me know if there is any other way to do this. I think there has to be an easier way to get changes uploaded to the server.

Thanks,
Erika

[Beth]

The common practice is to not check in the bin file, so the proper results as far as I know is for it to not go in through Visual Studio. You have to specifically select it and check it in manually.

[eday69]

Initially we didn't have the bin folder included, but when we would make changes to our .cs files and check them in, the changes wouldn't show up on the live server.

We figured out that we had to include the bin file in order for the server to recognize that a change had been made. If there is another way to do this I would love to know, but that was the only way we could get the server to see changes.

I just want to know how this needs to be configured so when we make changes to a .cs file and check it back in, the live server will recognize the change and compile the project.

Basically our problem is if we don't include the bin folder, changes will never get compiled on the live server. If we include the bin folder we have to jump through a bunch of loops to get it to work.

Thanks for your help,
Erika

[ian_sg]

I just want to know how this needs to be configured so when we make changes to a .cs file and check it back in, the live server will recognize the change and compile the project.

Basically our problem is if we don't include the bin folder, changes will never get compiled on the live server. If we include the bin folder we have to jump through a bunch of loops to get it to work.

There's been a couple of questions like this on the support forum lately. Essentially you're asking your version control tool to solve a non-version-control problem: compilation and deployment. Vault tracks changes to files. Usually these are source files. You can check in binaries, but Vault's not going to compile and/or deploy to a live server for you.

I think people sometimes expect Vault to solve this problem because they've previously worked on an application written exclusively in a scripting language like classic ASP. In this scenario, when you're using an interpreted script language, there is obviously no compile step. You can check the script into source control, do a Get Latest (or use shadow folders) on your production server, and voila: the live site is running the latest code.

When you move to .NET, you introduce a compilation step: your live web site needs not only the plain text markup files (e.g. aspx, ascx, etc), but also the DLLs that result from compiling the code. Vault won't do this for you. Often, people want the DLLs on a live server to be built with different options than those in use by developers. In .NET, for example, you probably want to enable compiler optimizations and disable debug symbols. In addition to the headaches you listed, this is a reason not to check in DLLs and deploy them using source control.

Last time I had to set up something like this from scratch, I created a NAnt script that compiled and deployed my code. Since then, MSBuild has come on the scene and is also probably worth a look. (This is not a remotely comprehensive list. This is far from my area of expertise nowadays.)

So to summarize, if I were you I would:

1. Remove build artifacts from source control: the web site project's bin folder, in the specific example you've given.
2. Investigate NAnt and MSBuild, and use one to write a script to build and deploy my web app.

I hope that helps.

[eday69]

Ian,
Thank you so much for this information. I really just wanted to make sure Vault was installed correctly and that the problem did indeed lie with .NET.

Thanks again.
Erika

[ian_sg]

Glad I could help.

[avonwyss]

To do what you want to do, use some continuous integration server such as CruiseControl.Net (which does, by the way, integrate well with Vault since there is a dedicated plugin available). The build server will then be configured so that on a check-in, it builds the source in the repository and if successful, publishes the result somewhere. A possible publication step could also be the deployment on a live system (which I would not do, but that is work-process-related and thus another story).

[ian_sg]

Thanks.