Jump to content

Menu Problem with CodeLab Plugins Built with Visual Studio


MJW
 Share

Recommended Posts

I'm trying to solve a vexing problem with plugins built from CodeLab-generated source code, but built under Visual Studio. The plugins are basically taken from the CodeLab "show source" output, copied into a file in a VS project, built, then the DLL is copied to the Effects folder. The problem is, sometimes they don't show up at all in the PDN Effects menu, and sometimes they show up twice. I even had one listed three times. The behavior is quite unpredictable. One didn't appear, so as an experiment I renamed the Effects folder to something else, created a new Effects folder, and added the plugin as its only member. When I ran PDN, the effect was listed. When copied it back to the real Effects folder, and changed the folder name back, the effect was listed twice. I don't have any idea what to look for, so any suggestions would be appreciated.

 

In the unlikely event anyone is curious enough to want to try it for him- or herself, here is the VS project: CodeLabTest.zip

Edited by MJW
Link to comment
Share on other sites

Some things to check:

 

1.  Check that the Target Framework is set to 3.5.  It should be. Find this under Project > Project Properties > Application tab.  This causes plugins to fail to show up in the menus.

 

2.  Versioning.  If you're saving under different filenames then the old versions will remain discoverable by paint.net @ startup.  Delete the old *.dll in between restarts or see next point. 

 

3. Build event - I'm not sure if you're overwriting the old *.dll in the pdn directory.  Here's my build event command line which manages it automatically       copy "$(TargetFileName)" "C:\Program Files\Paint.NET\Effects" /y

Link to comment
Share on other sites

Thank you, Ego Eram Reputo. I am building under 3.5. Most of the build is based on your VS template.  I'm pretty certain the file is being replaced. When two names are displayed in the menu, if I delete the DLL from Effects, both names disappear from the menu.

 

The one weird thing I'm doing, which had slipped my mind, is I'm copying the file over under a different name than the name VS creates the DLL under. All the the VS files are called "PluginEffect.dll," while each version in Effects is named after the plugin type based on the menu string. I suspect that may somehow be a problem, since all the plugins created like that share some common internal values. I'll bet that's it. Thanks for getting me to think along those lines! (It is frustrating, however, since that was a key part in my scheme to simplify VS plugin production.)

Edited by MJW
Link to comment
Share on other sites

^ Reckon this is it.

I believe that CodeLab takes the namespace from the name of the *.cs file. So naming your plugin is important. Using the VS template the namespace is derived from the project name you first type in to name your project.

Link to comment
Share on other sites

TechnoRobbo, the situation where you copy the file is different from mine. If you copy a file, the two files contain the same user assembly information, including such things as the AssemblyTitleAttribute. The DLLs I build are all from different Codelab-generated sources, so that information is different..

Link to comment
Share on other sites

CodeLab cleverly forces you to save your code before a build. Filename = namespace ;)

If you're copying that build into VS that might be the mechanism for the duplicated namespace.

Delete all the old dll's and try my build event command line. That should ensure there "can be only one."

Link to comment
Share on other sites

 

TechnoRobbo, the situation where you copy the file is different from mine.

Not if you haven't changed the DisplayName (and possibly StaticName) - the filename is irrelevant (Windows will take care of that kind of conflict)

Edited by TechnoRobbo

Go out there and be amazing. Have Fun, TR
TRsSig.png?raw=1
Some Pretty Pictures Some Cool Plugins

Link to comment
Share on other sites

Not if you haven't changed the DisplayName (and possibly StaticName) - the filename is irrelevant (Windows will take care of that kind of conflict)

 

All those are different between the separate plugins I built under VS. Each derived from a different CodeLab source with a different menu name. The only thing the plugins have in common, as far as I know, is that they were all built under the same VS Assembly name, EffectPlugin, so that's the DLL "internal name."

Edited by MJW
Link to comment
Share on other sites

Even if it's a problem to build different plugins under VS with the same Assembly name, I think I'll still be able to do what I was hoping to do, using another approach. I was under the impression it was difficult to change the Assembly name of a new project. However, some experimentation with WinMerge seems to show that changing the Assembly name of an unbuilt, unsaved project is as simple as changing a single line in the .csproj file. If anyone knows that's true, or knows differently, I hope they post a reply.

 

Added:

I should say, I thought it was difficult to change the name under VC# Express. The full version has a feature, under "Tools," called the "Add-in Manager," which seems to be missing from VC# Express.

Edited by MJW
Link to comment
Share on other sites

Change your references to PDN 3.5 they're currently 4.0

Use the same Namespace name in the "properties" and the code

 

Use " copy "$(TargetFileName)" "C:\Program Files\Paint.NET\Effects" /yas the post build events (make sure to use different Assembly names in the properties.

 

Make sure your error list is showing. It's giving your hints (CTRL+W,E)

Edited by TechnoRobbo

Go out there and be amazing. Have Fun, TR
TRsSig.png?raw=1
Some Pretty Pictures Some Cool Plugins

Link to comment
Share on other sites

In the situation I'm considering, it's easier than that. I'm copying a working CodeLab-based plugin project and then replacing the CodeLab source part of the project. If the original project is set up correctly with 3.5, the copied version will be, too. I hope this will become clearer in the near future.

Edited by MJW
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

 Share

×
×
  • Create New...