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

Can't use nuget packages with no framework versions specified #448

Closed
0x2Adr1 opened this issue Sep 7, 2024 · 5 comments
Closed

Can't use nuget packages with no framework versions specified #448

0x2Adr1 opened this issue Sep 7, 2024 · 5 comments

Comments

@0x2Adr1
Copy link

0x2Adr1 commented Sep 7, 2024

Example: WebSocketSharp: https://nuget.info/packages/WebSocketSharp/1.0.3-rc11

The generated BUILD file is missing websocket-sharp.dll

package(default_visibility = ["//visibility:public"])
exports_files(glob(["**"]))
load("@rules_dotnet//dotnet/private/rules/nuget:nuget_archive.bzl", "tfm_filegroup", "rid_filegroup")
filegroup(name = "libs", srcs = [])
filegroup(name = "refs", srcs = [])
filegroup(name = "analyzers", srcs = [])
filegroup(name = "data", srcs = [])
filegroup(name = "native", srcs = [])
filegroup(name = "content_files", srcs = [])
exports_files(["websocketsharp.1.0.3-rc11.nupkg"])

As a consequence depending on @paket.main//websocketsharp has no effect:

fsharp_binary(
    name = "foo",
    srcs = ["foo.fs"],
    deps = ["@paket.main//websocketsharp"],
)
error FS0039: The namespace or module 'WebSocketSharp' is not defined.
@0x2Adr1
Copy link
Author

0x2Adr1 commented Sep 7, 2024

I made it work with this diff, far from perfect though:

> git diff dotnet/private/rules/nuget/nuget_archive.bzl
diff --git a/dotnet/private/rules/nuget/nuget_archive.bzl b/dotnet/private/rules/nuget/nuget_archive.bzl
index bd25e52..b9ad6fa 100644
--- a/dotnet/private/rules/nuget/nuget_archive.bzl
+++ b/dotnet/private/rules/nuget/nuget_archive.bzl
@@ -108,7 +108,21 @@ def _process_group_with_tfm(groups, group_name, file):
     i = file.find("/")
     tfm_start = i + 1
     tfm_end = file.find("/", i + 1)
-    tfm = _replace_non_standard_tfm(file[tfm_start:tfm_end])
+    tfm_name = file[tfm_start:tfm_end]
+    tfm = _replace_non_standard_tfm(tfm_name)
+
+    group = groups[group_name]
+
+    # SPECIAL CASE FOR PACKAGES THAT HAVE THEIR DLLs DIRECTLY in lib/ LIKE WebSocketSharp
+    if tfm_end == -1:
+        filename = file[tfm_start:]
+        if filename.endswith(".dll"):
+            tfm = "netstandard2.0"
+            if not group.get(tfm):
+                group[tfm] = []
+
+            group[tfm].append(file)
+            return

     if tfm not in FRAMEWORK_COMPATIBILITY:
         return
@@ -117,8 +131,6 @@ def _process_group_with_tfm(groups, group_name, file):
     if file.find("/", tfm_end + 1) != -1:
         return

-    group = groups[group_name]
-
     if not group.get(tfm):
         group[tfm] = []

@purkhusid
Copy link
Collaborator

I'l take a look, pretty sure that I just lack handling where there are not TFMs declared in the lib folder in nuget packages.

@purkhusid
Copy link
Collaborator

Actually, I'm not sure if we want to support this after reading the NuGet folder structure conventions:

You should never have a version of the library that is not specific to a framework and placed directly in the root lib folder. (This capability was supported only with packages.config). Doing so would make the library compatible with any target framework and allow it to be installed anywhere, likely resulting in unexpected runtime errors. Adding assemblies in the root folder (such as lib\abc.dll) or subfolders (such as lib\abc\abc.dll) has been deprecated and is ignored when using the PackagesReference format.

If I'm reading this correctly then this package will probably also fail when using PackageReferencein MSBuild.

@purkhusid
Copy link
Collaborator

I would also be vary of this DLL, the repo for it looks very strange: sta/websocket-sharp#542 (comment). There are forks off it that have been published AFAIK?

@purkhusid
Copy link
Collaborator

Closing this since this behaviour reflects the MSBuild behaviour.

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

No branches or pull requests

2 participants