1

I have two applications developed in VS2010 (C#, .NET 4.0) - each is a separate solution with 2 projects, one for the app-specific elements, plus the project for a shared library which builds a DLL.

My problem is when this DLL is built, under one of the builds the DLL is 16384 bytes (0x4000) larger than it should be. This size difference is the same for both Debug and Release builds. WHile the proper version is within ClearCase, I get exactly the same result with a copy on the C: drive, so it doesn't seem to be a config-spec or view-related issue.

I've trawled through the VS settings, completely removed the bin/obj folders to force a complete rebuild, used WinMerge to diff all the files/folders, all with no success.

Using dumpbin, I can see in the clr header a 0x3F20 size difference for the Resources Directory. I suspect the remaining 0xE0 is attributable to section alignment within the DLL.

At this point I'm stumped. Any suggestions on what could be causing this or what steps to investigate further???

EDIT:

Maybe I didn't describe the VS solution very well - The solution has 2 projects. The shared library is simply added to the solution via Add->Existing Project. Both projects are then built when selecting Build->Rebuild Solution.

Re. Hans' comment, it's a problem from a configuration management/confidence standpoint. If no source code/project files have changed, the only thing I'd expect to change in the DLL is any build time/version details - not a 15K delta like I have.

Kevin Haines
  • 2,492
  • 3
  • 18
  • 19
  • 1
    There's no guarantee that the compiled binary will be equivalent each time you compile the exact same code, much less the impact that your project settings might have on the results. The real question is why you're trying to do this. Just build the DLL once and reference it from both projects. That's what everyone else does. – Cody Gray - on strike Feb 10 '12 at 02:07
  • 2
    Why is this a problem? What actually goes wrong using the DLL? – Hans Passant Feb 10 '12 at 02:14
  • Why does it cause an issue of confidence? Your unit tests are still passing, right? – Daniel Mann Feb 10 '12 at 02:48

1 Answers1

2

The problem was in the .suo (Solution User Options) file, which must have been corrupted (and unfortunately placed and maintained under version control by previous users). Thankfully it appears nothing significant is lost by the removal of this file.

A little more info on .suo files can be found in the SO question Why are there sln, suo and csproj files?

A quote from Debugger Settings Visual Studio Add In– Easily Copy Breakpoints between Machines sums it up well:

The .SUO file is the bane of your existence. Nearly all the problems you encounter with Visual Studio are the result of a corrupt .SUO file. Sadly, it seems all it takes to corrupt the .SUO file is your heart beating. In other words, whenever you have Visual Studio crash, refuse to debug, or behave strangely it's the .SUO file's fault. Whenever anyone asks me about strange Visual Studio behavior, my instantaneous response is "Delete the .SUO!" When it comes to Visual Studio hygiene, deleting the .SUO file is right up there with cancer screenings.

Community
  • 1
  • 1
Kevin Haines
  • 2,492
  • 3
  • 18
  • 19