1

I have some c# projects. I added post build event to those projects that copy the resulted assembly (dll) from the bin into common folder.

It appears that each compile generates assembly which is binary different from the previous even when I don't modify the project files.

It is quite a problem for me since I'm using Kiln that monitor those file and think they were modified.

I read somewhere that the dll stores time stamp of compilation which if true then I cannot fix this. If so how do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?

Thanks, Eran.

Eran Sakal
  • 35
  • 4
  • 1
    This is well known behavior: http://blogs.msdn.com/b/ericlippert/archive/2012/05/31/past-performance-is-no-guarantee-of-future-results.aspx: "the C# compiler by design never produces the same binary twice. The C# compiler embeds a freshly generated GUID in every assembly, every time you run it, thereby ensuring that no two assemblies are ever bit-for-bit identical" – Daniel Hilgarth Dec 05 '12 at 16:36
  • See http://stackoverflow.com/questions/1335427/why-does-c-sharp-generate-different-exes-for-the-same-source-code for info on why they are different – stuartd Dec 05 '12 at 16:37
  • @DanielHilgarth thanks for the quick reply. So does people handle this in terms of source control? It causes the repository to be enormous very fast... – Eran Sakal Dec 05 '12 at 16:48
  • 2
    FWIW, our shop tells source control to ignore certain files and folders - we don't see a need to put compiled assemblies in source control. – Mike Hildner Dec 05 '12 at 16:50

2 Answers2

0

To address the specific question of "How do you manage your shared DLL in such a way that your repository (Git/HG) doesn't commit all your compiled projects that weren't modified?", I have a very simple answer: ignore.

We exclude /bin and /obj from the directories which our source control will even attempt to commit. This does mean that you will need to recompile the code on each machine after each change, but Visual Studio would do that anyway for any project where the code has changed.

Bobson
  • 13,498
  • 5
  • 55
  • 80
  • But my application is split across several solutions (solution per layer). To share assemblies between those layers I must perform file reference to common/shared folder that holds all the relevant assemblies – Eran Sakal Dec 05 '12 at 17:00
  • @EranSakal - So what happens if someone makes a change to one solution that then breaks dll-compatability with the layer above it? Will they even know they made a breaking change? – Bobson Dec 05 '12 at 22:08
0

Don't commit the output folders of your projects.
If you want to have a Setup folder or something similar that always contains the latest versions of the assemblies created by your projects, the solution is to make sure that your post-build event is configured to run only when the build updates the project output. There is an option that is named like this:

enter image description here

Daniel Hilgarth
  • 171,043
  • 40
  • 335
  • 443
  • I thought setting this property but it will still occur in the following scenarios: 1. Rebuilding my solution. 2. cloning the repository from central location. – Eran Sakal Dec 05 '12 at 16:58
  • 1
    @EranSakal: You should think about why you actually want to put those assemblies into your VCS. There is no reason to do so. – Daniel Hilgarth Dec 05 '12 at 17:00
  • my application is split across several solutions (solution per layer). To share assemblies between those layers I must perform file reference to common/shared folder that holds all the relevant assemblies – Eran Sakal Dec 05 '12 at 17:06