xmouse-controls

xmouse-controls copied to clipboard

• Makes for easier execution on Windows systems without .net v3.5, but has .net v4+. No need for a separate app.config there, as it is today.
• Crashes on Windows systems with only .net v3.5.
• Targets application to (primarily) Windows 10, while leaving (primarily) Windows 7 behind.
  • Both are still popular, with a high number of users and large market shares.
  • September 2018:
    • Windows 10: 50.07%
    • Windows 7: 37.2%
• Can both systems be targeted at once, similar to #11/#12 but without app.config?

See

• https://github.com/joelpurra/xmouse-controls/issues/11
• https://github.com/joelpurra/xmouse-controls/pull/12
• https://en.wikipedia.org/wiki/Windows_10#Market_share_and_sales

Related to #11/#12. Looked at getting an embedded version of app.config working as well, but no luck so far. Just released a new "beta" version with a separate app.config in the zip file. Does that work for current users? Made a bunch of other changes, but hope for the best =)

https://joelpurra.com/projects/X-Mouse_Controls/

Have also moved the code from the SystemParametersInfoHelper library project into the main X-Mouse Controls.exe which means that without app.config there wouldn't be a need to download/unpack a .zip file with just a single .exe file inside. The current version works on Windows 7 (as it has .net v3.5), but not (primarily) fresh Windows 10 installs. I've attempted to target .net v4 here in #13, but then it plain crashes on Windows 7 (if the system doesn't have .net v4 already).

What's best -- a .zip file with an app.config or two separate .exe files for (primarily) Windows 7 and 10?

I like that SystemParametersInfoHelper was removed and I really do see the value of a self-sufficient .exe.

Unless there’s some other trick we don’t know about, I suspect a self-sufficient universal .exe would have to simply not be a .net executable. Perhaps it could be a silent unpacker or even just a replacement of the PE stub that Visual Studio prepends to executable assemblies. Cons for an unpacker/native approach:

• This would no longer be pure .net. A solution involving a native Windows executable could be justified because this application only targets the Windows platform and, e.g., it doesn’t know how to change the right configuration in a Mac OS X or a Linux desktop environment.
• This would add complication and I wouldn’t be able to implement it quickly unless there is some existing unpacker builder out there which could be used. I think 7-zip might support building these.
• Unpackers could make getting it to run harder for users in restricted environments. Such users would want to be able to run the .net part directly. Depending on the exact way we build the unpacker, users could still open it as an archive using 7-zip and grab the files they need.

So that might be a third option to think about. Does seem pretty ugly to me though ;-).

I don’t really feel very strongly about .config versus multiple executables. I like that the .config approach, from a build/development perspective, works out of the box and is closest to a “supported” scenario from VisualStudio. I also just think that it is cool that a single assembly file can load into either framework. If you go the multiple executables route, you’d probably want to make a script for your release process which handles setting all the build switches and file renaming properly for you. It would be cool that you could just offer two direct .exe downloads right on your website to let people skip the ZIP extraction step.