Zacki_...o,o...

Hi!

We just startet using tfs with vb.net.

We created a Partitioned Singel Solution Model and used a lot of project-references.

Now a user wants to run a solution, containing 30 projects.

Only 3 of them are supposed to be created, the rest is global stuff.

The output-files of the projects are under sourcecontrol.

So if a user runs the project, VB tries to replace the files in the (different) bin\debug-path of each of the 3 created projects. The Build-Process stops and an error occures, because the files in the bin\debug-path could not be replaced.

If the user manually checkes out the output-files before running the project, everything ist fine. But the user has to check out every file of each bin\debug-path of every project in the solution which is to be created. Of course, it is possible to do, but there should be a more technical way.

We started a workaround in which the sourcecontrol doesn't contain the output-files. But in this case, after getting the current version from server, every user has to compile the master-soltion, because without the output-files the project-references don't work.

Is it possible to automatically check in/out the output-files

Or can you see anything strange in our structure, as far as I told you

Thanx

Zacki



Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Eugene Zakhareyev

Why do you want to check out the outputs You mean that after every build you will check them in

In similar situation, we used to make sure that those source controlled outputs are made writable in pre-build step for every project (using simple attrib command). That will allow you to retain the structure and workaround the error of the compilation.

Regards, Eugene






Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Zacki_...o,o...

Hi Eugene!

The idea was:

Since rebuilding all files after downloading the current codes from sourcecontrol takes too much time, the only option left seems to be to put the output-files under source-control.

If we do this, of course, they are read-only.

So I thought, maybe we got something wrong here and there must be a simple solution for this, maybe by an auto-checkout for the output-files.

If I get you right, you manually removed the write-protection of the files in the local bin\debug-path.

Thanks for that.

But shouldn't there be a way of managing this problem with the given tools of TFS

Since we build the whole structure like described by MS, I would prefer a TFS-build-in solution for this problem!

Zacki





Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Michal Malecki - MSFT

Hello,

I think it's not recommended way to check-in binaries into SCC. That's why I'm not aware of any out of the box solution.
Are the sources changing frequently enough that you just can't build your source tree once and then build just single project you are working in Who is checking in updated binaries

Thanks






Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Zacki_...o,o...

Hi!

But what would be the recommended way to keep up-to-date with the source-files

I thought by using TFS, we wouldn't have to send "please get the current version of file xxx, I just rebuildt it!"-emails any longer. Since we just started to migrate our huge vb6-system to .net, there would be some mail-traffic...

Thanks for your suggestion. I think when the work on the basics is done, we could live with a local rebuild from time to time.

Still I would be very glad to here about how this procedure is officially meant to be handeled by MS!

Zacki





Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Michal Malecki - MSFT

In our case we mainly depend on the local builds. There are a few libraries that are checked-in. However, they are not stored in the output directory of the project that is used to build them - they are in the well known location that can be used by other projects that depend on them. This is what I would suggest for you - store all dependencies in other directory, make references to it, when somebody makes changes, he/she copies his changes to that directory and check them in.

To answer your question about up-to-date-files. The philosophy of TFS is that you are working in your workspace that was synced one time (when you started working) When you are done, you do check-in or get - if somebody modified any of the files you have modified, you will get conflicts and you will be able to resolve them.

Hope this helps






Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Zacki_...o,o...

>> The philosophy of TFS is that you are working in your workspace that was synced one time (when you started working) When you are done, you do check-in or get - if somebody modified any of the files you have modified, you will get conflicts and you will be able to resolve them.

When we learned about how to build our projects using .net, the msdn said, that "Project references are the preferred way to establish references to other assemblies and they are guaranteed to work on all development workstations in a team environment."

Manually putting the output-files in another directory and referencing the files would be the complete opposite.

And if your team is splitted across the globe and MS tells us that the TFS will be the right platform to connect them, I can't imagine that there has to be those manual steps...

So I start wondering if the MS-TFS really fits the MS-selfdefined standards for .Net-Projects.

Or maybe the TFS only works for teams of max. 3 people...

Zacki





Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Michal Malecki - MSFT

I would think twice about using TFS for with 3 people team - managing SQL Server, WSS, Reporting, boy, oh boy Smile

I didn't describe the recommended solution, because what you are doing is not recomended way. You should use only project references, never store the output-files.

The scenario is as follows:

Developer is working in his/her project and is compiling only project he/she touches. If he/she needs changes done to other projects, then yes - he/she needs to sync and build them as well. He/she needs to do full build only the first time he/she synced the solution and then from time to time, when big/breaking changes were checked in ito projects he/she is depending on. In my case build of whole TFS tree takes about 1 hour on the dev box, but I need to do it pretty rarely - every couple of weeks when breaking changes are coming from other teams. Then I can just leave build running over night.

Hope this helps






Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Zacki_...o,o...

"I didn't describe the recommended solution, because what you are doing is not recomended way."

> only because we were still searching for the recommended one

I think we allready work like you described it. Only since we're right at the start of our migration, we will have to continue sending some emails because there still some "big/breaking changes" every day. We'll see how it works.

Thank you very much!

Zacki

PS: I think a lot of my descriptions in my posts got lost in the german/english translation! Sorry for that!





Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Eugene Zakhareyev

Michal,

I think you can use binary outputs without moving them to separate folder in the solution/project structure. Let's say that I have these outputs in the source control, get latest on the whole project sub-tree and then try to build a few relevant projects I work with (as Zacki details above). Then if I unset the read-only flag in the pre-build, the only problem is that now outputs are different from SC and not checked out (while writable). Well, I do not see the problem here because if the outputs are updated only for the projects I work with, I clearly want them to be updated; for the other projects I will have the original version from SC . Now, if I have checked in all changes in project code and rebuilt it, I can choose to check in the outputs from that build (the local version).

In my opinion, the setup could be ok for smaller projects. And as for not storing binaries in the source control - that's a matter of approach; if your components have a defined release cycle, you may well have stable version of binaries checked in and use it (instead of compiling sources for the components).

Cheers, Eugene






Re: Team Foundation Server - Version Control General Problem: Checking out exe, dll, pdb-files

Michal Malecki - MSFT

Eugene,

I agree that storing the binaries depends on the project specifics and is sometimes right approach. I prefer to store the version controlled binaries in different just to separate files that others depend on and should be stable (possibly pre-tested etc.) from the files that I'm modifying all the time (by building). As always (and as you said) it has pros and cons. The one thing I would recommend - if you decide to check-in each build, I would check-in both sources and binaries in one changeset, to keep it consistent.