Quantcast
Channel: VBForums
Viewing all articles
Browse latest Browse all 15880

Framework Advice

$
0
0
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.

Viewing all articles
Browse latest Browse all 15880

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>