2

Can someone tell me how I can use the binary compatibilty in VS2010?

I have a project that evertime I build with a new assembly file with the new version changes the CLSID of the dll.

I already use that CLSID hardcoded in my WiX package to register that dll as a com+ but if it is to change on every build would mean I should update my WiX package with evey new version.

Any ideas ??

Edit 1

I should mention that this CLSID is the one that appears along side your Application ID in the properties window of your newley registered Com+ in component services. I have to hardcode them into the WiX file so it gets registered on install

Edit 2

Here is a link to another question that is related to what I am asking for more information WiX - Register ComPlus application and Assigning a role to a component

Community
  • 1
  • 1
AltF4_
  • 2,312
  • 5
  • 36
  • 56
  • 1
    Did you specify the `Guid` attribute on your class in your vb.net code? – Medinoc Jan 10 '14 at 10:50
  • Yes I have, it has a specific GUID set. what would happen without it? @Medinoc – AltF4_ Jan 10 '14 at 14:06
  • If it is set, I don't understand how it would change. I understand some GUIDs are to change with versions in an installer package (though I never used WiX, I did use VS2005 deployment projects, and the Product Code changed with version) I don't see how a CoClass's CLSID could change automatically if you set it in stone. *...Or perhaps you meant another kind of GUID in your question, instead of an actual CLSID?* – Medinoc Jan 10 '14 at 14:21
  • I think I meant a different CLSID... When you register your dll as a COM+ component and RHM and go to properties, you are presented with CLSID and an Application ID. When I change my Assembly Versiona dn file version , rebuild the project and re-register then that CLSID is different , if I revert back then CLSID would revert to its original value. So it is constant on each version. @Medinoc – AltF4_ Jan 10 '14 at 14:24
  • But CLSID shouldn't change with version... Normally, when you write your coclass in a .Net language for a COM-Visible assembly, you specify its CLSID in an attribute (`System.Runtime.InteropServices.GuidAttribute`) just before the `Class` keyword... – Medinoc Jan 10 '14 at 16:28
  • it does change, ive tested it. and setting the GUID the way you suggested doesnt make a difference in the result. @Medinoc – AltF4_ Jan 12 '14 at 15:18
  • Please share some code that reproduces this problem. – Holistic Developer Jan 14 '14 at 01:22
  • There is not code @HolisticDeveloper, its just the way a solution is built. If you register the dll that comesout of that solution in ComponentServices you can see the CLSID- then after a version change of the DLL the registered CLSID of the new dll would be different. – AltF4_ Jan 14 '14 at 10:03
  • @HolisticDeveloper I have added a link to a question similar to this. – AltF4_ Jan 14 '14 at 13:24
  • @AltF4_ If there is no code then what are you compiling? :) I was looking for how your class was defined and what attributes you had applied to it -- basically the info you posted in your answer. – Holistic Developer Jan 14 '14 at 17:15
  • Thanks @Medinoc your very initial comment put me in the right direction but i have added a full answer below. – AltF4_ Jan 19 '14 at 16:37

1 Answers1

2

I have found the solution thanks to MSDN,

By default, when you rebuild an assembly it is assigned a new version number. This is because Visual Studio .NET sets the AssemblyVersion attribute to "1.0.*" for new projects. As a result, a new Class Identifier (CLSID) is generated for serviced components each time the assembly is rebuilt.

Note This behavior is slightly different between C# and Visual Basic .NET projects. For C# projects, the assembly version is incremented every time it is rebuilt. For Visual Basic .NET projects, the assembly version is incremented the first time the project is rebuilt after it is loaded into Visual Studio .NET. Subsequent rebuilds within the same instance of Visual Studio .NET do not result in the assembly version being incremented.

This does not represent a problem, because the assembly version is for information only in assemblies that do not have a strong name. For strong named assemblies, you should use static version numbers that are manually maintained. This and other versioning issues are discussed further in Controlling Assembly Version in Chapter 5, "The Build Process".

In order to control the CLSID that serviced components end up with in the COM+ catalog and avoid multiple versions appearing each time a developer rebuilds the serviced component, use either of the following approaches:

1.Explicitly control the CLSID by using the following Guid attribute: 

[Guid("2136360E-FEBC-475a-95B4-3DDDD586E52A")]
public interface IFoo
{}

[TransactionAttribute(TransactionOption.Required),
Guid("57F01F20-9C0C-4e63-9588-720D5D537E66")]
public class Foo: ServicedComponent, IFoo
{}

2.Maintain a static assembly version number for the serviced component's assembly and don't use the Visual Studio .NET default "1.0.*" version numbering scheme. For more information about assembly versioning, see Controlling Assembly Version in Chapter 5, "The Build Process."

I used the first method. Worked a treat.

http://msdn.microsoft.com/en-us/library/ee817675.aspx

AltF4_
  • 2,312
  • 5
  • 36
  • 56
  • That's what I've been telling you to do this entire time, and you kept telling me it didn't work... – Medinoc Jan 21 '14 at 10:21
  • Yes, but you never mentioned '[TransactionAttribute(TransactionOption.Required)' mine was set to 'RequiresNew' plus I commented back and gave you credit for it :) – AltF4_ Jan 21 '14 at 11:17
  • Ah, I misunderstood your solution. I had no idea the `TransactionAttribute` had any influence on GUIDs. – Medinoc Jan 21 '14 at 12:31