Debugging a plugin

[chilio]

Yeah symbols not loading is about the most fun it gets :P

Normally that happens when you copy the wrong .dll but if you are using those commands that is not the cause (Also good catch modifying it for your dllexport.exe location). If you never make a skin that uses the plugin they will also never be loaded since Rainmeter will only load them in for the first time dynamically. Do you have a test skin loaded that is using the EmptyPlugin in one of its measures? If you do then that is another cause down, go to about>plugins tab and find your info is it displayed and if you change it and do a forced rebuild does it change as well?

I use this skin:

Code: Select all

[Rainmeter]
Update=1000
BackgroundMode=2
SolidColor=0,0,0,255

[MeasureEmpty]
Measure=Plugin
Plugin=Empty

[MeasureCpuMerge]
Measure=Plugin
Plugin=CpuMerge

[MeterText]
Meter=String
X=0
Y=0
Padding=20,20,20,20
FontColor=255,255,255,255
Text="hello world"

It does use Empty, but doesn't use CpuMerge. (I can safely remove CpuMerge, but not Empty.)
It does not appear in the plugins window, while Empty does. The file is in there, so that shouldn't be the problem. I have set the project as much as possible to be like Empty: "conditional compilation symbols" = "X64", "Platform target" = "x64", "Output path" = "x64/bin". I still couldn't get "Platform" = "Active(x64)" and still have "Active(Any CPU)".
My computer, VS and rainmeter installation are 64 bits, so it should build to x64 platform right? Otherwise I could imagine that would be the problem.

Is a force rebuild something other than right click on project file > rebuild? Rebuilding doesn't change anything for me at least.

[SilverAzide]

I have set the project as much as possible to be like Empty: "conditional compilation symbols" = "X64", "Platform target" = "x64", "Output path" = "x64/bin". I still couldn't get "Platform" = "Active(x64)" and still have "Active(Any CPU)".
My computer, VS and rainmeter installation are 64 bits, so it should build to x64 platform right? Otherwise I could imagine that would be the problem.

The reason your choice shows "AnyCPU" is that is the default for a new project in Visual Studio; if you want x64/x86-specific builds, you need to add these using the Configuration Manager. AnyCPU will work for you in the way you described your environment, but you cannot guarantee this is true for everyone. When set to AnyCPU, .NET executables auto-magically run in whatever "bitness" your OS is -- so they are 64-bit on 64-bit OS's and 32-bit on 32-bit OS's. This becomes a problem if -- for whatever reason -- someone is running 32-bit Rainmeter on a 64-bit machine. Then your plugin will crash Rainmeter with a "bad image format" exception, as the 32-bit host process attempts to load a 64-bit DLL. You might consider creating 64-bit only and 32-bit only configurations, and get rid of AnyCPU entirely to prevent any possible confusion.

This is why the Rainmeter SDK solution is set up the way it is. I suspect that a lot of your issues are due to creating your solution "outside" of (or independent of) the "SDK-CS.sln" SDK solution. This is why the Empty plugin is working and yours isn't. It would be simpler for you to add a copy of the Empty plugin (with lots of refactoring/renaming to change the name) as another project in the SDK solution. That way, you get all the logic that the SDK devs built into the solution.

[balala]

My computer, VS and rainmeter installation are 64 bits, so it should build to x64 platform right?

Beside SilverAzide's reply, you have to know that not necessary. In VS you can choose what version to be build. In fact, if you don't create the plugin just for your own usage, you have to create both versions, for the users who are using one or the other OS version.

[chilio]

Beside SilverAzide's reply, you have to know that not necessary. In VS you can choose what version to be build. In fact, if you don't create the plugin just for your own usage, you have to create both versions, for the users who are using one or the other OS version.

What you showed should show up, but for me it only shows Any CPU. I guess I'll add them by hand.

[jsmorley]

https://docs.rainmeter.net/developers/#CreatePlugin

[chilio]

The reason your choice shows "AnyCPU" is that is the default for a new project in Visual Studio; if you want x64/x86-specific builds, you need to add these using the Configuration Manager. AnyCPU will work for you in the way you described your environment, but you cannot guarantee this is true for everyone. When set to AnyCPU, .NET executables auto-magically run in whatever "bitness" your OS is -- so they are 64-bit on 64-bit OS's and 32-bit on 32-bit OS's. This becomes a problem if -- for whatever reason -- someone is running 32-bit Rainmeter on a 64-bit machine. Then your plugin will crash Rainmeter with a "bad image format" exception, as the 32-bit host process attempts to load a 64-bit DLL. You might consider creating 64-bit only and 32-bit only configurations, and get rid of AnyCPU entirely to prevent any possible confusion.

This is why the Rainmeter SDK solution is set up the way it is. I suspect that a lot of your issues are due to creating your solution "outside" of (or independent of) the "SDK-CS.sln" SDK solution. This is why the Empty plugin is working and yours isn't. It would be simpler for you to add a copy of the Empty plugin (with lots of refactoring/renaming to change the name) as another project in the SDK solution. That way, you get all the logic that the SDK devs built into the solution.

Then I'll trust the build-in magic and do that. I hoped to be able to understand the logic build into it to be able to debug easier and learn more VS magic
I should have time to insert my project into Empty tomorrow

[chilio]

https://docs.rainmeter.net/developers/#CreatePlugin

Balala was first ^^

I don't know if this will help, but have you seen this: https://docs.rainmeter.net/developers/#CreatePlugin?

[jsmorley]

It's just not worth the effort to try to build plugins outside of the Rainmeter Plugin SDK environment. We have everything all set up to easily create both 32bit and 64bit plugins that have all the hooks to be integrated into Rainmeter.

[jsmorley]

For C++:

In the SDK folder on your hard drive, make a copy of the PluginEmpty folder. Keep it in the same relative position in the folder structure.

copyfolder.png

renamefiles.png

renamefiles2.png

serachreplace.png

Find and run the program guidgen.exe found in this folder:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools

guidgen.png

{4B32465C-DC07-4EA1-91C8-F1ABCFDC9058}

Edit the file PluginMyPlugin.vcxproj in your text editor. Replace the ProgjectGuid with your new one.

Code: Select all

  <PropertyGroup Label="Globals">
    <ProjectGuid>{64FDEE97-6B7E-40E5-A489-ECA322825BC8}</ProjectGuid>

That's it. Now go up one level, and open SDK-CPP.sln in Visual Studio. Add your project to the solution, go nuts with coding your plugin, and you can easily build either 32bit or 64bit debug or release versions of your work.

[chilio]

For C++:

In the SDK folder on your hard drive, make a copy of the PluginEmpty folder. Keep it in the same relative position in the folder structure.

Find and run the program guidgen.exe found in this folder:

C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\Tools

guidgen.png
{4B32465C-DC07-4EA1-91C8-F1ABCFDC9058}

Edit the file PluginMyPlugin.vcxproj in your text editor. Replace the ProgjectGuid with your new one.

Code: Select all

  <PropertyGroup Label="Globals">
    <ProjectGuid>{64FDEE97-6B7E-40E5-A489-ECA322825BC8}</ProjectGuid>

That's it. Now go up one level, and open SDK-CPP.sln in Visual Studio. Add your project to the solution, go nuts with coding your plugin, and you can easily build either 32bit or 64bit debug or release versions of your work.

Jup, didn't expect that it really wasn't worth the effort to build it outside (I already had a solution outside, so yeah, that happened ^^
Thanks for posting the location and explanation of guidgen: I couldn't find it myself as I never have worked with it before.