Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support direct project references instead of NuGet for fast development loop #1268

Open
lukasf opened this issue Nov 6, 2022 · 1 comment
Labels
enhancement New feature or request

Comments

@lukasf
Copy link

lukasf commented Nov 6, 2022

Proposal: Support direct project references instead of NuGet for fast development loop

Summary

Using CsWinRT, it should be possible to add a winrt project reference to a test app or unit test project, and directly run the tests or the test app, without having to create a NuGet package.

Rationale

The recommended way of working with CsWinRT is creating an interop assembly and packing that as a NuGet package. That approach is fine for distributing libraries. But for the inner development loop as a library developer, this is very bad. Every time I change a line of source in the library, I have to build a new NuGet package with a new version number, I need to upgrade my unit test or test app projects to use the new NuGet version, only then I can build and run them. If I find out my change is not working, I have to rebuild it all again, create new NuGet, update, only to find out it might still not work. This also makes it difficult to automatically run unit tests on code changes, because the project would still reference and use the previous NuGet package, even if the source has changed.

This leads to horrible developer productivity. It must be possible to change a line of code in your winrt library and immediately launch the debugger or unit test!

Important Notes

If you directly run a test project with only a project reference (instead of NuGet package), you get "class not registered" exceptions. The reason is that the native dll is expected to be in e.g. runtimes\win10-x64\native, but the project reference will place them in the root output folder instead. If you move the native dlls into the corresponding output folders, the app or unit test will run fine.

Open Questions

In my opinion, this should be the default behavior, to allow seamless interop by default. But it could also be realized with a special property to be added in the project file. Not sure if the change would cause problems with existing projects, if it is enabled by default.

@lukasf lukasf added the enhancement New feature or request label Nov 6, 2022
@dongle-the-gadget
Copy link
Contributor

Currently blocked by #756.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request
Projects
None yet
Development

No branches or pull requests

2 participants