For example, let's say at one point I manually downloaded SignalR package and all dependencies and dropped the .NET Standard DLLs into my Unity project.
When you then add NuGetForUnity, those assemblies show up as "Already imported by Unity", which isn't true. So that's the first problem.
If I want to remove these DLLs and get the nuget packages installed through NuGetForUnity you quickly run into problems as the Install button cannot be enabled.
Removing the DLLs does not work because then your project fails to compile, and the last compiled version still has the DLLs loaded, and I assume this is why NuGetForUnity still doesn't allow the install with the same disabled button.
Possibly I could restart Unity Editor and Ignore the compile errors to get that button to enable. I did not think to try this. But I tend to avoid this anyway as it could cause problems with the project if you start changing things before a successful compile. So it's not an ideal workaround.
The only solution I found was to manually add each entry to packages.config by hand, including dependencies. This is not ideal. Once the project is building, I can then remove and readd nuget packages through the GUI to ensure everything is in a good state.
It would be nice if NuGetForUnity could detect this situation and allow the Install button, and remove any conflicting loose DLLs from your project for you (after a confirmation prompt).
It would also be nice if having a project that has loaded assemblies where the latest code doesn't compile, doesn't confuse NuGetForUnity into thinking assemblies are loaded that the user already deleted from disk.
Perhaps these both could be done by checking a loaded Assembly's .Location property to see if a) it is from Assets and b) if the file it points to has been deleted by the user.
It might also be nice if NuGetForUnity could detect when packages.config is missing dependencies and have some mechanism to offer to fix it for you. Though this is only a problem if you find a need to go manually editing it in the first place.
For example, let's say at one point I manually downloaded SignalR package and all dependencies and dropped the .NET Standard DLLs into my Unity project.
When you then add NuGetForUnity, those assemblies show up as "Already imported by Unity", which isn't true. So that's the first problem.
If I want to remove these DLLs and get the nuget packages installed through NuGetForUnity you quickly run into problems as the Install button cannot be enabled.
Removing the DLLs does not work because then your project fails to compile, and the last compiled version still has the DLLs loaded, and I assume this is why NuGetForUnity still doesn't allow the install with the same disabled button.
Possibly I could restart Unity Editor and Ignore the compile errors to get that button to enable. I did not think to try this. But I tend to avoid this anyway as it could cause problems with the project if you start changing things before a successful compile. So it's not an ideal workaround.
The only solution I found was to manually add each entry to packages.config by hand, including dependencies. This is not ideal. Once the project is building, I can then remove and readd nuget packages through the GUI to ensure everything is in a good state.
It would be nice if NuGetForUnity could detect this situation and allow the Install button, and remove any conflicting loose DLLs from your project for you (after a confirmation prompt).
It would also be nice if having a project that has loaded assemblies where the latest code doesn't compile, doesn't confuse NuGetForUnity into thinking assemblies are loaded that the user already deleted from disk.
Perhaps these both could be done by checking a loaded Assembly's .Location property to see if a) it is from Assets and b) if the file it points to has been deleted by the user.
It might also be nice if NuGetForUnity could detect when packages.config is missing dependencies and have some mechanism to offer to fix it for you. Though this is only a problem if you find a need to go manually editing it in the first place.