Please refer to the B96355 issue for more information.
This problem occurs only after rebuilding and can be easily resolved by restarting the IDE or reopening a solution.
Steps to Reproduce:
- Rebuild solution
- Open ModuleEditor for a XAF Windows Forms project
- Rebuild the XAF Windows Forms project - a "Reload ModelEditor" dialog appears, confirm reload.
The Model Editor is not reloaded with the "Dictionary already contains class info" error.
Thanks,
Dan.
Hi,
Is there already any progress on this bug?
I am getting the problem described with http://www.devexpress.com/issue=B96355 more and more. The cause described at B96355 from having 2 or more BO's with Module doesn't always appear to be the cause (or the exception raised is an indirect one).
The workaround of closing / reopening my solution is very annoyoing, because closing and reopening a solution containing currently about 20 projects takes quite long, let alone closing the IDE completely.
Anyway, I would greatly appreciate a solution for the problem.
Thanks
Marco
Hi Marco,
Thank you for the update. We apologize for the delay in fixing this bug. This problem is actually Microsoft's:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1928945&SiteID=1
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=352042
We are working hard to work around this problem and find a solution ourselves. For now, as a better workaround you don't use the Rebuild solution, but use the Build command.
In other words, the Build instead of Rebuild will prevent this issue.
Thanks,
Dennis
Hi Dennis,
Thank you for this update. I already had a feeling you guys where working on the issue. Still better to have a temporary work-around now.
Thanks!!!
Regards,
Marco
Hi (Dan?)
As this issue is marked duplicate with http://www.devexpress.com/issue=S30927 today, I wonder what's the problem with this 'multi-level' structure. Why does Visual Studio does not support this out of the box as you state?
Any Microsoft Support pages where these limitations are described?
Thanx,
Marco
Hello Marco,
I am working on a separate solution which will reproduce this issue and I will attach it to the "http://www.devexpress.com/issue=S30927" suggestion when it is ready. Then I will address it to the VisualStudio support team to see how it could be resolved.
Thanks,
Dan
Hi Dan,
I noticed that the linked issue http://www.devexpress.com/issue=S30927 has been rejected since 8/14/2009.
However, the problem still exists. So, i'm curious why the issue was rejected?
Thanks,
Marco
Hello Marco,
Thanks for contacting us. The suggestion you created has been rejected because, unfortunately, we cannot resolve the problem on our side. The actual problem relates to Visual Studio, and we could not bypass it. Microsoft has accepted this problem, but closed the bug as non-resolved in the current version of .NET Framework. Please look at the end of this suggestion for a link to the bug I reported to Microsoft.
So, we had to decline our suggestion because we cannot provide a solution on our side due to the above mentioned fact. However, you can use a workaround solution provided at the beginning of this suggestion.
Does the workaround solution work for you? If there is any problem, could you please provide us with instructions on how to reproduce it or may be even a small sample? We will be glad to review it and do our best to help you.
Thanks,
Dennis
Hi Dennis,
The workaround provided does not help always. The problem even occurs when using only the Build command.
However, I don't have a small reproducing example at this time and given the fact that the problem does not always show up,
it might be hard to create one.
So, let's hope MS will solve this problem in a future version of the framework / VS.
Marco
Hello Marco,
Thanks for contacting us. It's strange that this problem happens when using the Build command…
A small demo or instructions (if you do not have enough time to create a demo) on how to reproduce this problem with our demos or a newly created app will be very helpful, because I feel that this may be another problem than the one reported to MS. We cannot leave this as is, and so would appreciate your help in clarifying certain things.
You wrote that the workaround doesn't work for you (I assume you are talking about the Build command). If so, the duplicated suggestion contains two more possible workarounds that may solve the problem. The second one seems to be the most convenient.
Have you already tried them? Would they work for you?
Thanks,
Dennis
Hi Dennis,
As for the other two workarounds:
Closing and opening Visual Studio works in most cases. To be sure, I perform a build just before closing (so no additional build is needed after opening) and it works. However, this costs a lot of time having a solution of 33 projects.
Directly referencing output assemblies is not an option as I use different configurations (Release / Debug) a lot. When referencing an output assembly directly, AFAIK I have to choose for a Debug-build of that Assembly, or a Release build of that assembly. When referencing a project, Visual Studio (or MSBuild?) takes care of referencing the right assemblies.
As mentioned, I don't have an example and as I cannot predict when the problem may occur, it will be difficult to create one. But as I'm also on a tight timeframe currently, I may delve deeper into this when I've more time…
Regards,
Marco
Hello Marco,
Thanks for getting back to us. I understand you and also think that closing/reopening Visual Studio is not convenient, especially, if you have a large solution.
>>AFAIK I have to choose for a Debug-build of that Assembly, or a Release build of that assembly. When referencing a project, Visual Studio (or MSBuild?) takes care of referencing the right assemblies.
No, you can reference this assembly only once. This variant is good when you have a ready business class library that doesn't imply additional changes at all or imply rare changes.
We're waiting for your sample and appreciate your time. Thanks for your help in advance!
Thanks,
Dennis