xsharp.eu

In message https://www.xsharp.eu/forum/public-vo-v ... t=40#18499 Wolfgang wrote about using the NuGet manager or simply including a DLL:

"NuGet can do much more..."

Now I wonder what the best practice is. A programmer working on the .Net project, including X# conversion at my customer, created on (C#) program which included one NuGet package and a couple of Syncfusion DLL's, also retrieved from NuGet.

I cloned the project from BitBucket and most (or all) of these DLL's showed a faulty reference (yellow triangle icon). Nevertheless the NuGet Packages all seemed included. We removed them and tried to reinstall them, hoping that future pulls would keep the NuGet feeded DLL's at least in sync, but again a Syncfusion package showed as Installed while it was not included in the References.

My idea would be this:

1 For X# and related DLL's I would browse to the installation directory and pick the required DLL's manually, e.g. from C:Program Files (x86)XSharpAssemblies.
2 For all other 3rd party DLL's, including those obtained via NuGet, I would use a directory C:DotNetDLLs and keep all DLL's there and browse there to include.

This is the same location for all the users (now 2, will be more). It does mean that when there's an update we actually want to use that there are one or more manual steps:

1 The updated DLL's should be replaced in everyone's directories where the browse originally pointed to
2 Right mouse click in the project, Unload project, followed by Reload project with dependencies.

This seems to do the job properly without half or non working NuGet steps. Does this sound like a solid solution to keep everyone up to date? Or is there a better way?

Dick

Hi Dick,
as I use mainly XIDE for development, NuGet is not an option for me.
And I have encountered some DLL hell problems also with X# that required me to maintain separate projects for different applications.
For example, the Newtonsoft.Json.DLL I need for the Google Adwords application conflicts with the one I need in other projects, and the System.Threading.Tasks.Extensions.dll I need for my version of npgsql.dll conflicts with the one distributed with X# itself.
Therefore, I have a c:devNetLibs folder on my disk where I store all libs I need, complete also with my own libraries, and I search all libs from there.
I'm using also Github (having a paid account), but not to share my code.
Wolfgang

Dick,
The yellow icons for nuget packages are not a faulty reference but simply mean that the package reference (name and version number) is there, but you have not downloaded the package from the nuget website.
You can tell VS to do that automatically the first time you build the project from the Nuget Settings window (Tools - Nuget - Settings).
If you have set that already then there may be an error in the list of nuget sources (website where you are looking for nuget packages). The website where you need to load from could be unavailable.
You can also control these settings by adding a nuget.config file to the folder where your solution is.
For example:
https://github.com/X-Sharp/XSharpPublic ... Get.Config
This file tells VS that for the X# runtime and X# VS integration it should only use the official "nuget.org" website.
and this file
https://github.com/X-Sharp/XSharpDev/bl ... Get.Config
includes several other nuget website (because Roslyn depends on these)

Robert

Hello Robert, Wolfgang,

In short after your replies: what I planned to do seems a good practice. We can have 1 universal directory with DLL's because we don't have different versions. And NuGet proved it doesn't work to keep the references & DLL's included and working (I have the setting you mentioned checked but why am I not surprised something in VS doesn't work ) Probably a better name would be NoGet.

Instead of again spending time trying to fix some VS issue, a very frustrating thing which I have done too often already, it's better to just get the DLL's in a central directory and include them from there.


Dick

ic2 wrote:Probably a better name would be NoGet.

NuGet works a lot better, when you switch from Packages.config to PackageReferences. But this feature is (for my understanding) connected to the new project file format.

Hello Volkmar,

VR wrote:NuGet works a lot better, when you switch from Packages.config to PackageReferences. But this feature is (for my understanding) connected to the new project file format.

That is correct. Here's how to convert:
https://devblogs.microsoft.com/nuget/mi ... reference/

but as this conversion limits the supported projects, at least when it appeared in 2018, I can imagine that e.g. X# isn't supported? Or is it? C++ for example is only supported since July this year.

When I read that I suspect it's highly experimental and can probably best be avoided.

I think, despite your remark that the new packages come with a better working NuGet that I will proceed to download a NuGet package (as raw .nupkg file), rename that extension to .zip and extract whatever I need in a place & manner that I see & control what I am doing instead of relying on shaky VS 'features'.

Dick