views:

65

answers:

3

I have an application exe plus 3 referenced assemblies in a folder. Compiled in VS2010, CLR 4.0.

I'd like to modify the version of all 4 assemblies to match (1.0.0.0) and also modify the reference section in each of those assemblies to match the new version number.

Is that possible after the application was already build outside the IDE?

EDIT:

Here is the scenario: Our dlls are often installed in the GAC with a specific version. The version is only incremented when commercial products are released. We have many self written development tools that use some of those dlls that are installed in the GAC. The tools are build at a certain point and not rebuild when the code has changed. The CLR prefers to load the assembly from GAC though instead of the local assemblies, so many times our tools do not use the assemblies that they were build with. Thats a huge problem and I don't see how it could be solved otherwise.

+1  A: 

Use Reflector and its plugin Reflexil; of course, if the assemblies are signed they won't work together anymore (actually I think they won't work at all?). Otherwise you won't even need to modify the references I think.

Edit: also, Marc is absolutely right; can't imagine what scenario would absolutely require you to do this, it's quite hackish.

Alex Paven
I edited the post to show WHY I want do it, even it doesn't matter really...
testalino
Alright, I got it to work, but it takes really long to modify all assemblies. I'm looking at a different approach now. Thank you for your help though! Reflexil seems to be useful generally.
testalino
Don't know if this is what you're currently doing, but modifying the assembly file versions (at build time) separately from assembly versions (at release), if the references are specified with 'specific version', should generally have the desired effects. Not sure though, I know I've been bitten by the GAC many times before.
Alex Paven
Also, I _really_ don't mean to sound condescending, but giving the specifics of your requirements, not only of the problems you have with specific solutions, can often uncover very different solutions than you might have imagined, so that's generally a good idea.
Alex Paven
A: 

The simplest option is to simply rebuild and redeploy. There are things you can do in config (runtime/assemblyBinding/dependentAssembly/bindingRedirect), but that seems overkill here, since I'm not sure how you would go about changing the version numbers of the assemblies without rebuilding them, especially if they are signed/strong-named (the runtime will detect evil-doers).

It sounds like making work to me...

If the dlls are yours, just rebuild them with the right version meta. If they aren't yours, perhaps don't monkey with them.

Marc Gravell
A: 

Sounds like you need a publisher policy or a binding redirect. This will enable your assemblies to always use the latest version, or to use a specific version of a referenced assembly.

ShellShock
Like I said, the versions of the "latest" and current assembly are the same as the version is only incremented when a commercial product is released. Whether or not this is a good idea is a whole different story.
testalino