You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: