In my case, I had this situation:
- The target project was a .NET Core app.
- The EXE file was not .NET Core and had to remain EXE
I invented a workaround:
- Created a console app DLL project (.NET core) and added the EXE file as Embedded Resource inside it.
- Created a normal NuGet package for the new DLL file.
- In the target apps, I referenced this package (dll), so all future versions get updated in the normal NuGet way.
In the target app I added a post-build event to run the dll file:
dotnet TheDllName.dll
Packaged the DLL file in the normal way and referenced in the target app. In the which is dispatched in the normal way. Every time the NuGet package is updated, the new EXE will be also distributed inside the DLL. Then I used a command
What happens when the DLL runs?
- Reads the EXE file from itself, like any other embedded resource.
- Saves it on the disk as EXE file.
- Starts a new process to run the EXE file.
Optimization
This is not absolutely necessary, but to optimize the above process, I also added a version file (simple txt file named ver.txt) to record the version number of the EXE file, so I only extract and save it once per updated NuGet package.