Before completing this for all different Visual Studio versions etc I would like some input if a complete pull request in the line of these changes would be acceptable.

Good question. I'm in favor of setting git-tfs to be "Any CPU", and #619 did that. But #1019 changed it back to "x86", because of checkin policies that are built as x86.

I'm interested to hear if this fixes #1117. That said, git-tfs shouldn't be using that much memory, and there probably is another fix that would make git-tfs work in x86 mode.

HI @spraints, thanks for the feedback !

When doing the pull requests all checks passed so hopefully it is all good :)

I do agree that there is probably something that could reduce memory consumption however this is not something I have the time to fix.

However I realize that there might be tons of things about the code I have not considered so if there are any negative side effects please let me know!

I will get back to you regarding #1117, cloning is still in progress.

#1117 was resolved by these changes

But #1019 changed it back to "x86", because of checkin policies that are built as x86.

&

When doing the pull requests all checks passed so hopefully it is all good :)

@JensNordenbro
That is not that simple :(
Our unit tests (and smoke tests) doesn't test checkin policies that occures only when checking in TFVC.
Which is also one of the main raison why we maintain different version for each TFS version....

So, I don't know what we should do....

@pmiossec - you make me confused.
I noticed in the solution that there are different Visual studio csproj-files for different Visual Studio versions but not the part about "different version for each TFS-version". Maybe it is the TFS version it reflects?

Is there anything I can do to proceed or is this a matter of changing/disabling the checkin-policy that is neccessary?

@pmiossec Would making two releases, one for "x86" and one for "any CPU" solve the problem?
I have also been hit by bug #1117 and would appreciate a solution.

@EdorianDark , did you try out my fork?

@JensNordenbro No, but I am certain, that it would solve the problem.

@pmiossec, do you have any comment to our questions? I would accept a reject but it would be nice to get a definitive reject or directions for approval (aside from the merge from master).

We have 2 possibilities :

• use 'AnyCpu' and break the use of check-in policies
• use 'x86' and sometimes have an out of memory exception when cloning. An operation that could be continued...

I think we should look around playing with the 32bit flag like described in this post:

https://lostechies.com/gabrielschenker/2009/10/21/force-net-application-to-run-in-32bit-process-on-64bit-os/

Perhaps providing 2 exe, one with the flag on and one with the flag off.

That requires some tests...

Some other options:

• ship only AnyCPU and write up directions for how to use corflags to change it if you need to.
• build as AnyCPU, but use corflags to mark the distributed exe as x86, and write up directions on how to undo that.

My personal preference is to ship only one exe, because I think it makes for a better UX. In this case, shipping two exes is probably the best experience. I think I'd make git-tfs.exe be x86, and git-tfs-x64.exe would be the same binary but flagged to run as x64. How does that sound?

These TFVC policies you talk about @pmiossec ; are they failing because of rule forbidding Any Cpu or is it some technical reason that breaks all checkin-policy rules?

@spraints

Some other options [...] How does that sound?

Very good summary of my point of view. I am perfectly in line with that point of view.

The only choice remaining is which one will be the default. I can't make a choice. I don't know which one will annoy the less people...

(and test if corflags exists on the build server and update the build and packaging)

@JensNordenbro

These TFVC policies you talk about @pmiossec ; are they failing because of rule forbidding Any Cpu or is it some technical reason that breaks all checkin-policy rules?

When there are checkin policies defined on the server, the TFS client assemblies try to load client assembies to do the checkin. But at the moment, these assemblies are only provided as x86 by Microsoft.
So, to be able to checkin when there are such policies, git-tfs should be able to load these assemblies so be run as x86. If git-tfs is compiled as 'AnyCpu' and run as x64 because run on an OS 64bit (which is run by most users), then it can't load the assemblies, so can't checkin.

I think that there are not a lot of user in this case nor ones encountering the OutOfMemory Exception.
So, I don't know what should be the state of the flag "Prefer32bit"...

Anyway, please change all the projects as "AnyCPU", we will figure it out later for the flag...

VS runs (or used to) as x86. So checkin policies would always run as x86. A pure .NET DLL that's built as x86 or as AnyCPU would run fine in this scenario. Problems happen if the policy DLL is x86 and git-tfs is AnyCPU.

But at the moment, these assemblies are only provided as x86 by Microsoft.

Ugh, really? If MS is still distributing DLLs as x86, then my vote is that git-tfs should default to running in x86 mode. I think my vote is that git-tfs should default to running in x86 mode anyway. I guess we could be clever and run AnyCPU for everything, and the run an x86 shim exe to do checkins?

Closing due to #1138

Tried it. I had been having repeated out-of-memory errors while trying to clone a large TFS repo (resulting git repo: ~5GB, packed), and no longer had any using this build.

@m-akinc It would be great, if you could test #1138