So while this allows plugins without .exe, this a) makes it harder to run it manually in debug mode, b) results in a mix of plugins with and without .exe?

So while this allows plugins without .exe, this a) makes it harder to run it manually in debug mode, b) results in a mix of plugins with and without .exe?

Microsoft requires a specific format and name, which is why the problem persists. To resolve this, we must deploy all binaries on Microsoft Windows with the .exe extension.

Update: This is what Windows is expecting: Common file name extension

@ralphm

a) makes it harder to run it manually in debug mode,

How? Have you tried it?

• I didn't have any problems running it in the debug mode. I used the Command Prompt app.
• Win users don't really need to run go.d.plugin in the debug mode because they can use dyncfg.

@ralphm

a) makes it harder to run it manually in debug mode,

How? Have you tried it?

• I didn't have any problems running it in the debug mode. I used the Command Prompt app.

That's great then.

• Win users don't really need to run go.d.plugin in the debug mode because they can use dyncfg.

We regularly ask people to run plugins in debug mode to get more detailed logs for support requests. Why wouldn't that apply to Windows users?

We regularly ask people to run plugins in debug mode

What plugins are we talking about? Are there multiple ones? I think there's only one. And it's usually used for debugging data collection jobs. Using dyncfg is a simpler and faster approach. Do we really ask win users to use terminal to debug data collection jobs?

@ilyam8 ,

We were talking about missing extension addressed by this PR:

So while this allows plugins without .exe, this a) makes it harder to run it manually in debug mode, b) results in a mix of plugins with and without .exe?

I will check for other plugins that may be missing file extensions and will ensure all of them have the appropriate extensions when compiled on Microsoft Windows.