Hello together,
we would like to change our application from Infragistics 2010.03 to the current version.
We have the following problem: Our application consists of about 100 solutions. Most of them have references to infragistics. Unfortunately, the solutions are all interwoven. Solution "A" points to "B" and Solution "B" points back to "C" or back to "A". Now you can not just change all solutions one after the other because they can not be compiled anymore.
Is there a viable way to solve this problem or do we really have to change our architecture?
Kindly Regards, Karsten Heimer.
(I hope, this english is correct, it is the result of the Google Translator)
Hello Alan, I have tried your solution, but it does not work. There are just too many DLLs interwoven. The picture clearly shows my problem. The red circles are the infragistics DLLs, the gray rectangles are our own DLLs. The lines in between are the references.
I would say, my first task is to significantly reduce the number of references. Then we will see further.
Hello Alan,
i will try your Workaround. Working with the "Alias Property" sounds good. I will give Feedback as soon as possible.
Thank you and have a nice Weekend, Karsten Heimer.
Karsten,
I did a simple test with a new solution and two class libraries and Visual Studio 2017 wouldn't let me add the circular reference so I added it manually myself in the project file. If I did this before building the assemblies, visual studio wasn't able to build the assemblies. If I manually removed the circular reference, built both class libraries and then added the circular reference in manually, visual studio was able to build both while they referenced each other as long as they had been build before so the dll could be found.
I believe that you might be able to work around your compilation issue with the project A and project B example by doing the following (though I haven't tested this):
If I am correct at that point in both resulting assemblies should work together and reference only the newer version of our toolset.
If you are unsure what the Aliases property does, the question on StackOverflow: What use is the Aliases property of assembly references in Visual Studio 8 may be of interest to you.
Note that i would recommend that you consider changing your architecture to remove the circular dependencies. An example of one approach to do this is on Code Project: What is Circular Dependency and How Do We Resolve It?
Let me know if you have any questions.
thank you for your answer.
Note that in your post you mentioned that you have project A and it points to project B, I assume this means that project A references project B. And you mentioned that project B might reference back to project A. Do you indeed have circular references like this? I believe visual studio would give an error dialog if you actually tried to do that.
KH: Yes, we have such circular references (Oh, don't ask why...) It works with Visaul Studio, because of every Solution is in a single Solution-Map.
If you do indeed have references like this, then you might have an issue in compiling the assemblies because each assembly would need to be compiled to compile the other assembly and neither would succeed if you didn't already have one compiled.
KH: Yes, this is actually our Problem. That's why I think about changing the architecture. I am afraid that we have to put all codes, which depend on Infragistics, into a single DLL.
The version-free assemblies don't really solve anything in that if you are calling from one assembly of yours to another and passing any objects in the IG assemblies, the exact version must be used in both assemblies on your side. Note that Mike suggested starting with the assemblies that have the least dependencies in the chain. This means that you should start with assemblies that reference our controls and don't reference any other assemblies or a smaller set of assemblies.
You might also want to review the known issues and breaking changes section of the help to see if there are any breaking changes relevant to your application. If not, the expectation is that you can update the assemblies and the application will compile. If you post the first ten errors for a project, we might be able to give hints as to what is likely causing the issue.
Note that in your post you mentioned that you have project A and it points to project B, I assume this means that project A references project B. And you mentioned that project B might reference back to project A. Do you indeed have circular references like this? I believe visual studio would give an error dialog if you actually tried to do that. If you do indeed have references like this, then you might have an issue in compiling the assemblies because each assembly would need to be compiled to compile the other assembly and neither would succeed if you didn't already have one compiled.