Skip updating assemblyversion of one file during VS/msbuild action
We have a Visual Studio 2010 solution that we build with FB6. We update the version information by first reading this from an ini file into a PropertySet. We use that PropertySet inside the Build VS.Net Solution action to “update assembly info for .Net projects”.
When we do this, all versions are updated as expected.
But we have one assembly that we use from a VB6 application. And so the assembly is a com interop assembly. We found that when we change the assembly version (in FB or just on a dev machine inside VS), new guids are generated for the interop. And this prevents the VB6 app to find the assembly. We do not want to update the VB6 app to fix the reference.
So long story short:
- Is there a way to prevent FB to update the assembly version for just one of the projects inside the solution, maybe with some action script or some msbuild prebuild event?
And a bit off topic:
- Would we be saved if we use late binding inside VB6 in this situation, or is it still using the guids when locating the assembly ?
- How do other FB users organise VB6/.Net combined projects? Always build and update/deploy both .Net interops and the VB apps using them?
- I think VB6 projects themselves have the same problem. Does anyone have some tips about how to deal with versioning and not always building all VB6 projects that make use of another ocx/dll
Just for your info: The guids that are created do not seam to be real guids. When building a specific version of a .net interop project it will generate the exact same guids on all machines. So building version 1.1.0.139 on system A will result in exact the same guid as when I build version 1.1.0.139 on system B. When changing just the version on both systems to 1.1.0.153 this will result in exact the same guids for both systems (but different from 1.1.0.139). Something I did not expect. It does not matter if I build with FB/MsBuild or on a devmachine inside VS.
On the VS.NET action, on the .NET version tab, at the bottom of the tab is an option to apply the assembly info to all projects in the solution or just selected projects.
I’m affraid I can’t help you much with the VB6 stuff, I gave up working with it in 1998 and the other devs here are all too young to remember it!
The VB6 action does have an option to fix up ActiveX references… but that relies on the new type library having been registered first (so you would need to register the interop dll before building the VB6 project.
I tested the “Apply to” option in the “build VS.Net Solution” on the “.Net Version” tab, but it does not work. When I select all project in the solution but one, all projects will get versionnumber 1.0.0.0., not only the one I have deselected.
This is a bit like I expected, because in my eyes this “Apply to” projectlist belongs to the “Assembly Version” and “File Version” parts, that are disabled when you use “Use Property Set for Version Info”.
I also tried to not use “Use Property Set for Version Info” and instead use the propertyset-parts in the “Assembly Version” fields, but that has the same effect setting all version numbers to 1.0.0.0.
I just tested this here and I’m not able to reproduce this. I also looked a the source code and whether you use a property set or not the Apply to project list remains enabled and the selected list is respected.
I suspect what may be happening here is that you have a duplicate project id in your .sln file. Open the .sln file in notepad and make sure each project referenced by the solution has a unique guid id. The reason for this is that we reference projects by Id not by name (the UI shows the name), if the unselected project has the same id as a selected one then that might account for it being updated. Also, there is a newer build of FB6 available on our website, I don’t think there was anything changed in this area but it’s worth testing.
The projects in the solution all have a different Guid.
I cannot update the FB version yet because another project is running on the same server and that project is in a final stage.
As soon as possible I will try out some different settings for the action. Until then I will try out a workaround by splitting compile into two actions, and setting the fileversion of the com interop .Net project with the tool stampver.
Well, it took a lot more time than I hoped before I could get back to the project and had the chance to investigate further. No luck yet.
I made a screenshot of the result and put it in a zip together with the solution and two of the vb project files and the FB project file. Could you please take a look if I am doing something wrong here?
The problem is that in my solution there is a project “Norma DOT API”. I do not see the project in the list. Probably I saw it in the list once, but I am not sure. We were using an earlier build of FB6 but now the latest build of FB6: 2253
Is there a way to achieve this via scripts as a workaround? Can I loop te projects in a solution in a script and enable them?
I tried to add the solutions and projects as attachment, but did not succeed yet.
