2

I have a DLL compiled under .NET 3.5 which represents a POCO data model. The client application is limited to .NET 3.5 and the DLL must be shared by both the client and server, so recompiling the DLL isn't an option.

I am attempting to rewrite the server REST API as an ASP.NET Core MVC project (using the 1.0 release and the Preview 2 tools under VS2015). I tried updating the project.json with the so-called "bin syntax" as shown below, but the package restore log shows a bunch of errors such as:

error: Package Microsoft.NETCore.App 1.0.0 is not compatible with net35 (.NETFramework,Version=v3.5). Package Microsoft.NETCore.App 1.0.0 supports: netcoreapp1.0 (.NETCoreApp,Version=v1.0)

"frameworks": {
"netcoreapp1.0": {
    "imports": [ "dotnet5.6", "portable-net45+win8" ]
},
"net35": {
    "bin": { "assembly": "c:\\source\\externaldllsdebug\\datadef.dll" }
}

I also tried setting up a nuget package in the DLL folder then making the folder a new nuget source. It opened the package fine but failed when it attempted to import the DLLs.

Nate Barbettini
  • 51,256
  • 26
  • 134
  • 147
McGuireV10
  • 9,572
  • 5
  • 48
  • 64

1 Answers1

1

I don't think what you are trying to do is possible currently.

An alternate solution would be to refactor the project that produces the shared DLL to produce a library that would be compatible with both .NET 3.5 and netcoreapp1.0:

"frameworks": {
    "net35": { },
    "netstandard1.1": {
        "dependencies": {
            "NETStandard.Library": "1.6.0"
        }
    }
}

This way, you could produce a DLL that still worked in your .NET 3.5 project, and also one that could be installed in your ASP.NET Core project without any issues or hacks.

Nate Barbettini
  • 51,256
  • 26
  • 134
  • 147
  • As you probably know, this produces two DLLs. While it's easier than maintaining two projects, as you note, this isn't really what I'd hoped to do, but I appreciate the suggestion. I imagine this is the right approach if I wanted to pursue the NuGet package angle. – McGuireV10 Jul 16 '16 at 11:26
  • @McGuireV10 Yeah, it does produce two DLLs. But if you package it via NuGet, only one will get installed in the project. – Nate Barbettini Jul 16 '16 at 15:46
  • 1
    I'll give you credit for the answer. After additional poking around it turns out the DLL wasn't as vanilla as I was led to believe, so it won't be compatible with Core without some alternative dependency declarations (versus mscorlib on the 3.5 side) so NuGet gymnastics are unavoidable. – McGuireV10 Jul 16 '16 at 17:54
  • @McGuireV10 I'm sure you've seen this already, but it's really easy to produce multi-targeted NuGet packages with `dotnet pack`. If you have a project definition like the one above, the pack command will output a NuGet file that will install the correct DLL (+ dependencies) in both types of projects. – Nate Barbettini Jul 17 '16 at 00:06
  • 1
    There is no netstandard or pcl profile that targets 3.5 at all, so producing two assemblies is your best choice. – Richard Szalay Jul 17 '16 at 00:17
  • @NateBarbettini Thanks, I've been using the NuGet GUI to produce the package (it actually involves about six DLLs), but that leads to a mismatch between the new package and whatever NuGet has cached in the global-packages, requiring me to nuke that cache to pick up the right versions in the referencing project. I suspect I'm doing something wrong but I haven't had time to try to research it further. – McGuireV10 Jul 18 '16 at 15:20
  • @McGuireV10 You should be able to avoid that by always incrementing the package version. – Nate Barbettini Jul 18 '16 at 15:47
  • @NateBarbettini I assumed as much but I'm guessing I'll then accumulate a pile of unneeded old-version packages in the cache, no? Or is NuGet smart enough to keep the cache tidy? (Obviously I haven't done any testing. Never had much of a need for NuGet prior to this, apart from grabbing the occasional EF update or what have you.) – McGuireV10 Jul 20 '16 at 11:53
  • 1
    @McGuireV10 Probably, but unless you have extremely low disk space I don't think it would be an issue. – Nate Barbettini Jul 20 '16 at 16:09
  • @NateBarbettini so how exactly do i create the two libraries? The answer above is not clear to me – flexxxit Feb 16 '17 at 14:16
  • @flexxxit You are probably looking for `dotnet pack`. Feel free to open a new question if you're having trouble creating a package. – Nate Barbettini Feb 16 '17 at 15:35