Best Way To Solve This?
-
Background I have a WPF app in which I'm using DevExpress Reporting. To create a report based off a List there is a wizard which allows you to choose "Object Data Source". When you choose that you see a list of entities in your app that are marked with the attribute "[HighlightedClass]". This attribute is defined in the namespace "DevExpress.DataAccess.ObjectBinding". My WPF UI, DAL, BL, and entities are all defined in seperate projects. This all works fine. Problem Now I'm working on a Xamarin Forms project that will use the same DAL, BL, and entities to pull data from the WPF project into an Android app. My shared mobile project has references to the DAL, BL, and entities. And this is where the problem is... when I deploy to the Android I get deployment errors saying that the Android project can't resolve references to DevExpress assemblies. I'm sure that if I were to remove the "[HighlightedClass]" attribute from the Entities project then everyting would deploy fine. But then I would not be able to create new reports in the WPF project. Possible Solution One idea I have is to create local models in the WPF project for reporting. My UI project could call back into the back end, get back a list of data as LIST, them map them to local models which would use the attribute. This way the attribute only appears in the WPF project where the reporting happens. The Entities project would no longer know about DevExpress. And the Android app would no longer complain about it. But this is a lot of work and could create maintenance headaches as I would have local Models that are exact duplicates of the Entity classes in the Entites project. I would have to make changes in two places. I'm open to suggestion here. Thanks
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
-
Background I have a WPF app in which I'm using DevExpress Reporting. To create a report based off a List there is a wizard which allows you to choose "Object Data Source". When you choose that you see a list of entities in your app that are marked with the attribute "[HighlightedClass]". This attribute is defined in the namespace "DevExpress.DataAccess.ObjectBinding". My WPF UI, DAL, BL, and entities are all defined in seperate projects. This all works fine. Problem Now I'm working on a Xamarin Forms project that will use the same DAL, BL, and entities to pull data from the WPF project into an Android app. My shared mobile project has references to the DAL, BL, and entities. And this is where the problem is... when I deploy to the Android I get deployment errors saying that the Android project can't resolve references to DevExpress assemblies. I'm sure that if I were to remove the "[HighlightedClass]" attribute from the Entities project then everyting would deploy fine. But then I would not be able to create new reports in the WPF project. Possible Solution One idea I have is to create local models in the WPF project for reporting. My UI project could call back into the back end, get back a list of data as LIST, them map them to local models which would use the attribute. This way the attribute only appears in the WPF project where the reporting happens. The Entities project would no longer know about DevExpress. And the Android app would no longer complain about it. But this is a lot of work and could create maintenance headaches as I would have local Models that are exact duplicates of the Entity classes in the Entites project. I would have to make changes in two places. I'm open to suggestion here. Thanks
If it's not broken, fix it until it is. Everything makes sense in someone's mind. Ya can't fix stupid.
Have you considered creating your own [HighlightedClass] stub attribute in the correct namespace that could be used as a stand-in reference in the other project? It would just need to be compile compatible with the real class. Or possibly even it is compiled as a source only attribute in one context… This leads to a scenario where you might want the same source to be shared across two different projects so it can be compiled two different ways? Or use it as a binary dependency? You have 2 versions of a DLL?