Class Interface's uuid and DispID are changed when migrating from Visual Studio 2010 to 2012

Question 1

You showed too little of your C# code, I don't see if you're using [DispId] attributes on the public methods of your class. Also, you didn't answer my question in the comments about the COM client binding type. What is the nature of your COM client code?

If it is late-bound, chances are your could still save the situation with relatively little efforts, by providing exactly the same DispId attributes for your methods as they were generated by VS2010.

In case of early binding (most often used with C++ COM clients), you still could try to simulate the layout of your old, VS2010-generated class interface with a new, manually defined, fine-tuned C# interface, to preserve the binary compatibility (including the IID, methods layout and DispIds). In this case, your new class would look like this (note the new ComDefaultInterface(typeof(_XXadapter)) attribute):

[ComVisible(true)]
[ClassInterface(ClassInterfaceType.None)]
[ComDefaultInterface(typeof(_XXadapter))]
[ComSourceInterfaces(typeof(_IXXXEvents))]
[Guid("15******-****-****-****-************")]
public partial class XXadapter: _XXadapter, ICOMInterface
{
    // ...
}

Now, the new _XXadapter interface I'm talking about would look like this:

// keep the IID and methods layout as generated by VS2010 for _XXadapter,
// the way it appears in the IDL from OleView (interface _XXadapter)

[ComVisible(true)]
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
[Guid("E8****-****-****-****-************")] 
public interface _XXadapter {
    [DispId(00000000)]
    string ToString { get; }

    [DispId(0x60020001)]
    bool Equals([In] object obj);

    // etc...
}

This way, you may be able to get away without recompiling your COM client.

Moreover, it appears the XXadapter class now has to implement both _XXadapter and IComInterface interfaces which have the same method names. This can be done using two explicit implementations, sharing the common code, i.e.:

public partial class XXadapter: _XXadapter, ICOMInterface
{
    void _XXadapter.Method_one() { this.InternalMethodOne(); }

    void ICOMInterface.Method_one() { this.InternalMethodOne(); }

    private void InternalMethodOne() { /* the actual implementation */ }
}

Thus, the InternalMethodOne method would contain the actual logic.

Question 2

The guids have to change, a rock-hard requirement in COM. The underlying core mistake you made is exposing the class implementation. Visible from seeing the System.Object methods getting exposed in your coclass, like ToString, Equals, etc. Which exposed you to the risk of the compiler re-arranging the method order, an undefined implementation detail.

The right way to do it is to always make the implementation invisible. Like this:

[InterfaceType(ComInterfaceType.InterfaceIsDual)]
[Guid("put the IID here")]
public interface IXXadapter {
    string ToString();
    bool Equals(object obj);
    int GetHashCode();
    Type GetType();
    // etc...
}

[ClassInterface(ClassInterfaceType.None)]
[Guid("put the CLSID here")]
public class XXadapter : IXXadapter {
    // etc..
}

Note ClassInterfaceType.None, that hides the class internals. The COM client only sees the interface declarations, they are fixed and the order is predictable. I included the 4 System.Object methods that you originally exposed, you don't have to write their implementation. That should rescue your binary compatibility, just ensure you update the [Guid] attributes to match the old ones.