Framework Advice

I'm contemplating a change, and thought I'd ask on here to get a fuller picture of my options before I get into trying things out.

The situation is this: I currently have a project that makes use of a couple dlls that it references. The main project references roughly five dlls. The main project and four of the dlls that the main project references all reference a dll called Common. The point of the Common dll is a series of tools, interfaces, enums, and class definitions used between the projects.

In addition to this small set of dlls, the project is a plug-in system, so it dynamically loads other dlls on startup. These aren't referenced by the project, they are just files that are opened up, and some classes found in the dlls are instantiated so long as they implement one of a few interfaces found in Common. Therefore, the projects that create the plugin all reference Common, but the Common dll is not found with the plugins. The plugin files are just files in a folder. The Common dll is found with the main application (which loads the dlls), and that is good enough. Since the main application loads Common, the types defined in Common are available to the objects created from the plugin.

This whole structure has been written against framework 4.0. There are roughly 30 plugin files. So, there is the main program, four dlls referenced by the main program, and about 30 files also referencing Common.

The problem is that a few of the objects in Common are base classes that make use of XNA, which was a thing back in 2010. It is STILL a bit of a thing, but the thing is now Mono Game, which is the XNA framework continued forwards as an open source project once MS abandoned XNA. Mono Game can work with VS 2010, but there is no no very good reason to stick with 4.0. I was remaining with 4.0 because XNA stopped with VS2010, and some kludgy stuff had to happen to get it working with newer versions of VS. Mono Game works BETTER with newer versions, so if I switch to Mono Game I can move on from FW 4.0. There are a variety of advantages to doing so, but none of them are absolutely essential, so I have the luxury of thinking about the change before making it.

So, the big question is what this does to the plugins? The main project is 4.0. If Common is upgraded to target 4.7.2, I get a mass of warnings (just warnings) because the main project and the four dlls, all of which reference Common are still built against 4.0. Moving them to 4.7.2 would be painless. However, every plugin project is still targeting 4.0. I would expect that they would all run fine, and each could be left as is, or moved to 4.7.2. Opening any of the plugin projects would result in that same warning, since they target a different framework than the framework that Common targeted.

Is there anything that will trip me up on this? Can I leave the plugins targeting 4.0 and referencing a dll that targets 4.7.2 without any problems being encountered? I believe it should be fine, as the plugins are just using a subset of the language that would be available to them had they targeted 4.7.2 from the start, but I wanted to be sure that was the only issue. Every one of the plugins could move on, but once you get to 30 projects....what a pain in the butt it is to do that, trivial though it would be.

Quote:

---

I believe it should be fine, as the plugins are just using a subset of the language that would be available to them had they targeted 4.7.2 from the start, but I wanted to be sure that was the only issue.

---

I wish I could speak from personal experience to provide you with a more confident answer, but I fairly certain that your assumption is correct.

If I were in your position I would upgrade and make the jump to mono. Not only because XNA is dead, but in hindsight it never really was alive.

I disagree that it never really was alive. It was quite alive for many more years than I was aware of it. And then it ended like it hit a wall. When the VB6 partisans were voting for MS to bring back VB6 over on Microsofts User Voice forum, they liked to note how many votes they got, but they were something like third. Far ahead of them was bringing back XNA. It was also popular enough that MonoGame took over XNA immediately and began to extend it.

Having thought it over for a time, I believe that it really is time to cut loose of FW4.0 overall. I was astonished at how easy it was to move from XNA to MonoGame, and getting a vibrant, active, community rather than a download that couldn't readily be added to any VS instance beyond 2010 would be good. A painless transition makes it easier.

The other reason I wasn't moving on is that some of the development was being done on a Surface Pro 2. When I bought that device, I spec'd it out to match the computer I had at work such that anything that ran well on that would run well on the computers I was targeting. I had some processor intensive stuff, so that was reasonable at the time. Technically, VS2019 will run on the setup I have on that Surface, but it's less than the recommended hardware, especially for RAM. I bought that Surface so I could work on stuff while going on a month-long bike ride of an odd sort. Now, I have good reason to upgrade to either a Surface Pro 6 or 7, because I'm contemplating an even stranger bike ride for the spring. The new Surface Pro devices are even better suited for bike packing than the 2 was, so I can get one with better specs in every way (better keyboard, bigger screen, lighter weight, MUCH longer battery life, more power, and considerably more RAM) cause I'll have something nutty to do, again.

After a bit more study, I'm not sure that this will work. As it turns out, one of the plugins was never tested all that well. That's no surprise, it was written very recently in some haste, and bugs happen. If I open the project, I had the same issues mentioned in the last post, but by visiting all the errors, they all went away nicely. That left me with a bunch of warnings, as expected.

The project won't build, though. Despite having only warnings, it simply won't build. This appears to be a bit of a known issue. If you have a project targeting 4.0, and it references something that targets 4.5, and 4.5 is available, it looks like the build will simply fail, despite there being no true conflict. This would mean that there is no way to debug the plugins without bringing them up to 4.7.2.

On the face of it, that's not bad, but it does appear to mean that there is a fundamental incompatibility between the frameworks that I'll have to think more about. Saying, "you can write a plugin....but it has to target this" is not really the objective I had.

One thing that is clear is that this is an issue with Mono Game and VS. None of the warnings have anything to do with the Common dll referencing 4.7.2, they are all about Mono Game related dlls referencing 4.5. So, moving all the Mono Game stuff out of Common is one option. The graphics base classes could be in a different dll. Those plugins that needed them would have to reference 4.5 or later, while the plugins that didn't use those graphics could still target 4.0.

That seems like a viable work around for what looks like a VS builder bug:

https://stackoverflow.com/questions/...gainst-a-highe