Concurrent 2.1 and 2.5 plugin Development

[JonathonReinhart]

Hello - Is anyone out there maintaining plugins for both 2.1 and 2.5? How are you doing it?

On my latest plugin, I marked my main class as "partial" so it can be split across multiple files (just like most Forms are, with the Form.cs and Form.Designer.cs files). Then I put everything in the one file except for the Startup() function. In 2.1 it returns List<Form> but in 2.5 it is void. Then I have my own private startup() function in the main class file.

From here, I duplicate the *.csproj file, and name one _21 and one _25. In one I reference Vixen.exe 2.1.x.x, and the other I reference Vixen.exe 2.5.x.x So the two projects are identical as far as source files go. At this point, they won't compile because they're missing the Startup() functions. So in each project, I add a Startup_2x.cs and implement the correct signature of Startup() and just call my private startup() function. (I never have any MDI windows anyway). Then change each project's output file name, and when I build the whole solution, I get a nice _21 and _25 .dll file in the bin directory.

Clear as mud? :-D Hope this helps anyone trying to keep plugins working for both versions without having to change code in two totally separate projects. If there's an easier way, let me know!

[teberle]

Take a look at the #define. You can specify custom conditions during compilation.

[j1sys]

I FIGURED IT OUT!!!!

Seriously I have come up with a procedure that allows me to have one solution/project/source and dynamically (semi) generate two different plugins.

A few caveats:

1) you should have both Vixen 2.1.x.x and Vixen 2.5.x.x installed on your machine in two separate directories. My working example uses: c:\Vixen2.1 and c:\Vixen2.5 directories. It is only important that they use something like this to allow the Post Build task to copy the completed plugin to your work area for testing. If you don't mind moving plugin .dlls around you don't HAVE to do this.

2) I've only tested this with VS 2008 Standard. It should work with other releases but it is untested.

3) To change versions for building you must select the Configuration named Vixen2.1 or Vixen2.5 (it needs to match your directory names for automatic copying), then close the solution, then reopen it and work on that version. You can NOT change the Configuration and immediately re-build. The system has to reparse the XML file for the project and insert the appropriate Vixen.exe path name.

The system includes defined variables that allow conditional compilation of the differences needed to compile against the two different versions.

I will make a training video of ALL the steps (a lot) needed to get this setup and post it soon. I will include a 'Blank' Plugin that can be used for a template but THAT will need more work to really be ready for prime time. I also figured out, partially, how to inject a dialog into the MDI. Still a little idiosyncronatic but it works for me.

So, yes Virginia, there is a Santa Claus.

-Ed

[djulien]

Hello - Is anyone out there maintaining plugins for both 2.1 and 2.5? How are you doing it?

I just create 2 subprojects that use all the same source files, but import a different Vixen.exe and also use a different value for a #define set within the project settings. When I compile the whole solution, it compiles both versions of the plug-in DLL.

don