Impact of identical GUID across applications

Whenever I have a new C# project, I often copy/rename an existing one in order to re-use most of the code. This means going into Assembly Info and renaming the project in there as well. In the past, I haven't really bothered with renaming the GUID.

Is this bad programming practice and could it negatively impact the user if they have another program open with the same GUID?

开发者_运维知识库I am by no means an expert programmer, but I get by and I figure things out as I go along. Any advice would be welcome.

I would say blind copy/paste vs smart re-use is in general a bad practice, but if you update the values in the assemblyInfo you might be on the safe side.

Personally I always assign a different Guid to every project if I copy that file, but anyway the AssemblyGuid attribute is used only for COM interoperability so if you are making pure .NET class libraries or applications and you have ComVisible set to false because you don't expose anything via COM, you shouldn't worry and there wont be any impact on anything else.

If you are copy/pasting so often, consider extracting the common code into a library and referencing it from your other projects. This has advantages due the reduced maintenance when you make a change of fix a bug.

It depends on what the GUIDs are used for. Some re-uses of GUIDs that I know that can cause severe (and yet subtle) complications are:

1. GUIDs exposed to COM in any way. If two COM components with the same GUIDs are ever registered there will be very confusing and near-impossible-to-resolve conflicts.
2. GUIDs which are product IDs in setup projects. It isn't very fun to run into a situation where a different product is uninstalled and/or otherwise prevents installation.
3. Most GUIDs in SharePoint. (Column types, timer jobs, etc.)

In the end, I would look for other methods of "re-use" if possible.

Happy coding.

I don't know .Net, but in most languages you can package reusable code into a library. Keep the source to your library in just one project, then link to the binary of the library from each of your main applications.

If you persist with the copy-n-paste code reuse, you will quickly find that maintenance becomes a nightmare. It's much better that reusable code be kept in one place so that when you fix a bug, it's fixed for all of the programs that use it.