davkean
commented
9 years ago Continuing from #20. I'd rather not use rundll32.exe, I'd rather a real CLI interface to handle this.
Well powershell Cmdlets, not CLI arguments, but why not both if someone wants to control the audio device from cmd.exe.
For CLI arguments I don't need to do this. For powershell cmdlets, I need this to be a DLL, not an exe so I can load it as a powershell module.
Maybe the powershell cmdlets just need to be in a separate dll.
I see. Have a few questions:
- How well do old-school console apps play with PowerShell? I assume by above that you'd expect Get-AudioDevice to actually return a AudioDevice representation itself, right?
- It's clear what Set-AudioDevice will do (although, there's no good unique friendly "name" to represent a device, though maybe the non-unique description "Speakers" might be good enough). But what do you want to do with Get-AudioDevice? What would you do with the result? Perhaps filter and then pass result to Set-AudioDevice?
zippy1981
I can open separate issues for these, but I think the "should we" needs to be discussed together.
It would be cool to have some powershell methods for switching the audio device from the CLI, for those of us into that kind of thing. Two that come to mind are of course
Get-AudioDevice [-Active] [-Filter]andSet-AudioDevice [-Name]To do that you need a DLL, not an exe. Rather than make a DLL and a wrapper EXE, it would be simpler to replace the
static void Main()call with a call that rundll32.exe can make via UnmanagedExports The chocolatey package can then include a batch file to start this up manually, and add that batch file to the start menu.Also, once this is a DLL, it makes sense to make this a regular nuget package and supporting an API as well.