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 Karsten,
Thank you for contacting Infragistics!
You shouldn’t have to change your architecture. You will have to upgrade all the projects all at once and then rebuild all. Then start resolving any build errors starting with the project with the least amount of dependencies of other projects.
You can also look into using our version utility to help in the process of upgrading our controls. With the version utility you can select a solution and tell it what to upgrade, the following link documents how you can use the version utility:
Upgrading A Project Using Version Utility
Hello Mike, I'm not sure this way works. Even the solution with the fewest compile errors still has hundreds of them. I would have to comment out a lot of codes. Our software is very, very interwoven. In some cases, we pass whole infragistics events (example: Validating, CellChanged) per parameter.What about the "version-free" DLLs? Can these be easily exchanged for a newer version in the future?
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.