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

.net core projects only support referencing .net framework assemblies in this release #1672

Closed
dotnetdeveloper786 opened this Issue Jul 15, 2016 · 50 comments

Comments

Projects
None yet
@dotnetdeveloper786

dotnetdeveloper786 commented Jul 15, 2016

i am getting this error when i am trying to add reference of 3rd party dll that not on nuget i am using Asp.Net Core Web Application(.Net Framework Standard 4.6)

untitled23

@rdefreitas

This comment has been minimized.

Show comment
Hide comment
@rdefreitas

rdefreitas Jul 15, 2016

Can you provide any details of the 3rd party DLL?

rdefreitas commented Jul 15, 2016

Can you provide any details of the 3rd party DLL?

@dotnetdeveloper786

This comment has been minimized.

Show comment
Hide comment
@dotnetdeveloper786

dotnetdeveloper786 Jul 16, 2016

Yes Stripe.dll and SimplePsd.dll both are not available on nuget

dotnetdeveloper786 commented Jul 16, 2016

Yes Stripe.dll and SimplePsd.dll both are not available on nuget

@MV10

This comment has been minimized.

Show comment
Hide comment
@MV10

MV10 Jul 16, 2016

@rdefreitas the DLL details don't matter, VS2015 throws this error trying to reference any DLL via the Add Reference dialog. Fire up VS and build a simple class project then try to reference that DLL from any core project (even a console app) and you'll see this message every time.

Our team really wants to begin using MVC Core because we don't want to base a large new years-long project on the old stand-alone WebAPI, yet this problem is giving us a lot of heartburn. We can get around it with NuGet packaging but that's a big hassle when the DLLs are in active development and changing frequently (versus just referencing them in a centralized build-target folder somewhere).

MV10 commented Jul 16, 2016

@rdefreitas the DLL details don't matter, VS2015 throws this error trying to reference any DLL via the Add Reference dialog. Fire up VS and build a simple class project then try to reference that DLL from any core project (even a console app) and you'll see this message every time.

Our team really wants to begin using MVC Core because we don't want to base a large new years-long project on the old stand-alone WebAPI, yet this problem is giving us a lot of heartburn. We can get around it with NuGet packaging but that's a big hassle when the DLLs are in active development and changing frequently (versus just referencing them in a centralized build-target folder somewhere).

@rdefreitas

This comment has been minimized.

Show comment
Hide comment
@rdefreitas

rdefreitas Jul 16, 2016

@MV10 @dotnetdeveloper786 I didn't try this with the current version of the tooling for Visual Studio... it was one of the nightly builds sitting on my machine at the time.

I'll see if I can figure out a workaround, as I've got a couple of projects where I did pull this off.

rdefreitas commented Jul 16, 2016

@MV10 @dotnetdeveloper786 I didn't try this with the current version of the tooling for Visual Studio... it was one of the nightly builds sitting on my machine at the time.

I'll see if I can figure out a workaround, as I've got a couple of projects where I did pull this off.

@MV10

This comment has been minimized.

Show comment
Hide comment
@MV10

MV10 Jul 16, 2016

In my case this is with VS2015 Update3 and .NET Core 1.0 with tooling Preview 2, which I think is still current. (Since it also affects things like Core console projects I wondered if it might belong over in one of the rosyln gits somewhere...)

MV10 commented Jul 16, 2016

In my case this is with VS2015 Update3 and .NET Core 1.0 with tooling Preview 2, which I think is still current. (Since it also affects things like Core console projects I wondered if it might belong over in one of the rosyln gits somewhere...)

@rdefreitas

This comment has been minimized.

Show comment
Hide comment
@rdefreitas

rdefreitas Jul 16, 2016

@MV10 this is probably the right place to start...
@rowanmiller do you know who the right person on the team would be to look at this, or the best repo to open an issue is?

rdefreitas commented Jul 16, 2016

@MV10 this is probably the right place to start...
@rowanmiller do you know who the right person on the team would be to look at this, or the best repo to open an issue is?

@dotnetdeveloper786

This comment has been minimized.

Show comment
Hide comment
@dotnetdeveloper786

dotnetdeveloper786 Jul 17, 2016

@MV10 @rowanmiller but if i create portable class library and than i add that dll as reference and then i add this portable library reference in my core web application it's working fine but i am not able to add reference of that dll directly in to my core web application it throws me above exception
so what to do?

dotnetdeveloper786 commented Jul 17, 2016

@MV10 @rowanmiller but if i create portable class library and than i add that dll as reference and then i add this portable library reference in my core web application it's working fine but i am not able to add reference of that dll directly in to my core web application it throws me above exception
so what to do?

@MV10

This comment has been minimized.

Show comment
Hide comment
@MV10

MV10 Jul 17, 2016

@dotnetdeveloper786 yes, my point was that it doesn't matter what kind of DLL you try to add, a core project always shows that error. I was agreeing with you and that is the issue they're investigating now.

MV10 commented Jul 17, 2016

@dotnetdeveloper786 yes, my point was that it doesn't matter what kind of DLL you try to add, a core project always shows that error. I was agreeing with you and that is the issue they're investigating now.

@rdefreitas

This comment has been minimized.

Show comment
Hide comment
@rdefreitas

rdefreitas Jul 17, 2016

@MV10 that's why I asked Rowan. He's a member of the asp.net team and would probably know who the best person is to address this. I'm just a lowly community member like you ;-)

rdefreitas commented Jul 17, 2016

@MV10 that's why I asked Rowan. He's a member of the asp.net team and would probably know who the best person is to address this. I'm just a lowly community member like you ;-)

@gulbanana

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana Jul 18, 2016

it is likely that the conversion back to msbuild will fix this issue

gulbanana commented Jul 18, 2016

it is likely that the conversion back to msbuild will fix this issue

@avoxm

This comment has been minimized.

Show comment
Hide comment
@avoxm

avoxm Jul 23, 2016

I am having the same problem. Is there any workaround for this ?

avoxm commented Jul 23, 2016

I am having the same problem. Is there any workaround for this ?

@MV10

This comment has been minimized.

Show comment
Hide comment
@MV10

MV10 Jul 23, 2016

I have to put my files into a NuGet package locally, set up that folder as a NuGet source, browse to the package and load it up that way. Then when I change the DLLs, I update the package then update the version (and filename) and load the new file. Or, since I don't want useless old packages proliferating, save with the same version/filename, blow away the global package cache (batch file), then do a full restore in all referencing projects (which, incidentally, also requires me to close all open VS instances otherwise NuGet will throw file-locked errors).

It's pretty annoying. (And in my case it's worse than that since part of the project requires a companion set of .NET 3.5 assemblies and isn't NuGet compatible, so there is more batch-file jockeying to update that project too.)

How this got through testing without anybody doing a simple Add Reference is beyond me. Isn't that what Unit Test coverage is all about? Do they really not have test coverage for VS and tools???

MV10 commented Jul 23, 2016

I have to put my files into a NuGet package locally, set up that folder as a NuGet source, browse to the package and load it up that way. Then when I change the DLLs, I update the package then update the version (and filename) and load the new file. Or, since I don't want useless old packages proliferating, save with the same version/filename, blow away the global package cache (batch file), then do a full restore in all referencing projects (which, incidentally, also requires me to close all open VS instances otherwise NuGet will throw file-locked errors).

It's pretty annoying. (And in my case it's worse than that since part of the project requires a companion set of .NET 3.5 assemblies and isn't NuGet compatible, so there is more batch-file jockeying to update that project too.)

How this got through testing without anybody doing a simple Add Reference is beyond me. Isn't that what Unit Test coverage is all about? Do they really not have test coverage for VS and tools???

@harald

This comment has been minimized.

Show comment
Hide comment
@harald

harald Jul 25, 2016

Same problem here (VS Update 3, Tooling Preview 2). This is more than annoying. It makes .NET Core pretty much useless for enterprise development. When will this be solved?

harald commented Jul 25, 2016

Same problem here (VS Update 3, Tooling Preview 2). This is more than annoying. It makes .NET Core pretty much useless for enterprise development. When will this be solved?

@MV10

This comment has been minimized.

Show comment
Hide comment
@MV10

MV10 Jul 26, 2016

Another report: 1612
And a dupe by the same OP: 1661

I've noticed this issue posted in other repos as well (and not getting any official attention).

I still question whether "aspnet" is the right repo area for reporting this issue (and having any chance of somebody from MS paying attention to it). Awhile back I stumbled across a repo called "roslyn-project-files" or something similar, which sounds like it might be an exact match for the team that might care about this, but I spent 90 minutes this morning paging thru github project lists and search results, and I can't find it again. Ring any bells with anybody?

Edit, found it: roslyn-project-system

Is that a better place to report this issue?

@AArnott, since you work with VS at the project level can you perhaps comment or offer guidance?

MV10 commented Jul 26, 2016

Another report: 1612
And a dupe by the same OP: 1661

I've noticed this issue posted in other repos as well (and not getting any official attention).

I still question whether "aspnet" is the right repo area for reporting this issue (and having any chance of somebody from MS paying attention to it). Awhile back I stumbled across a repo called "roslyn-project-files" or something similar, which sounds like it might be an exact match for the team that might care about this, but I spent 90 minutes this morning paging thru github project lists and search results, and I can't find it again. Ring any bells with anybody?

Edit, found it: roslyn-project-system

Is that a better place to report this issue?

@AArnott, since you work with VS at the project level can you perhaps comment or offer guidance?

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Jul 26, 2016

If your focus is on ASP.NET scenarios, this is probably the right place.
roslyn-project-system is for a new C#/VB project system (based on CPS) that includes .NET Core support I believe, but may or may not replace ASP.NET's project system for web scenarios (I just don't know).

AArnott commented Jul 26, 2016

If your focus is on ASP.NET scenarios, this is probably the right place.
roslyn-project-system is for a new C#/VB project system (based on CPS) that includes .NET Core support I believe, but may or may not replace ASP.NET's project system for web scenarios (I just don't know).

@Tenmak

This comment has been minimized.

Show comment
Hide comment
@Tenmak

Tenmak Jul 28, 2016

Then I don't get either why nobody is answering to that bug... I mean... it's very annoying not to be able to reference a single .NET 4.X DLL...

Tenmak commented Jul 28, 2016

Then I don't get either why nobody is answering to that bug... I mean... it's very annoying not to be able to reference a single .NET 4.X DLL...

@harald

This comment has been minimized.

Show comment
Hide comment
@harald

harald Jul 28, 2016

Indeed. The very existence of that bug suggests to me that whoever is developing .NET Core is not actually using it for any real-life projects. As MV10 already said, it is really puzzling how such a fundamental bug could possibly slip through basic testing.

I was tasked to assess if .NET Core is ready for production development.
My answer at this point is a clear No.

harald commented Jul 28, 2016

Indeed. The very existence of that bug suggests to me that whoever is developing .NET Core is not actually using it for any real-life projects. As MV10 already said, it is really puzzling how such a fundamental bug could possibly slip through basic testing.

I was tasked to assess if .NET Core is ready for production development.
My answer at this point is a clear No.

@AArnott

This comment has been minimized.

Show comment
Hide comment
@AArnott

AArnott Jul 28, 2016

The history of this from my understanding is that the folks who developed the tooling we have today envisioned every single project belonging to their system, and their system creates nuget packages automatically for every assembly. So it wasn't an issue, if you were entirely in the new system.

Going forward the tooling will be MSBuild based, and I expect that means assembly references will be allowed again.

AArnott commented Jul 28, 2016

The history of this from my understanding is that the folks who developed the tooling we have today envisioned every single project belonging to their system, and their system creates nuget packages automatically for every assembly. So it wasn't an issue, if you were entirely in the new system.

Going forward the tooling will be MSBuild based, and I expect that means assembly references will be allowed again.

@muratg

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Aug 2, 2016

Member

I recommend reporting this on dotnet/cli or dotnet/corefx repos, as this is not an ASP.NET problem.

And I think @AArnott is right.

Member

muratg commented Aug 2, 2016

I recommend reporting this on dotnet/cli or dotnet/corefx repos, as this is not an ASP.NET problem.

And I think @AArnott is right.

@MV10

This comment has been minimized.

Show comment
Hide comment
@MV10

MV10 Aug 2, 2016

@muratg I don't have need to use the command line tools myself so I haven't tested whether it's a problem at that level, and corefx is about the core libraries which definitely doesn't sound relevant to project/reference issues.

@AArnott are you saying we probably have to wait for VS 15?

MV10 commented Aug 2, 2016

@muratg I don't have need to use the command line tools myself so I haven't tested whether it's a problem at that level, and corefx is about the core libraries which definitely doesn't sound relevant to project/reference issues.

@AArnott are you saying we probably have to wait for VS 15?

@muratg

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Aug 2, 2016

Member

Referencing stuff is all in CLI now (It's true that ASP.NET had that before we moved from DNX to dotnet.)

Member

muratg commented Aug 2, 2016

Referencing stuff is all in CLI now (It's true that ASP.NET had that before we moved from DNX to dotnet.)

@MV10

This comment has been minimized.

Show comment
Hide comment
@MV10

MV10 Aug 3, 2016

@muratg Can you set up a quick test and let us know how it goes? On the VS side you can literally create a stubbed-out do-nothing DLL then ref from a console project and it fails. I'll be happy to move the report over there if it's a problem.

This issue brought our decision to use core to a screeching halt on a very large project (and everybody I know in the enterprise world was already unnerved by the project.json/msbuild overnight reversal).

MV10 commented Aug 3, 2016

@muratg Can you set up a quick test and let us know how it goes? On the VS side you can literally create a stubbed-out do-nothing DLL then ref from a console project and it fails. I'll be happy to move the report over there if it's a problem.

This issue brought our decision to use core to a screeching halt on a very large project (and everybody I know in the enterprise world was already unnerved by the project.json/msbuild overnight reversal).

@muratg

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Aug 3, 2016

Member

@MV10 Sorry, don't have time. There's enough people reporting the problem (including yourself), so I do believe that there's an issue. :)

Member

muratg commented Aug 3, 2016

@MV10 Sorry, don't have time. There's enough people reporting the problem (including yourself), so I do believe that there's an issue. :)

@muratg

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Aug 3, 2016

Member

cc @piotrpMSFT

Member

muratg commented Aug 3, 2016

cc @piotrpMSFT

@TheRealPiotrP

This comment has been minimized.

Show comment
Hide comment
@TheRealPiotrP

TheRealPiotrP Aug 3, 2016

@MV10 please see the pattern for wrapping loose dll's here:
https://github.com/dotnet/cli/tree/rel/1.0.0/TestAssets/TestProjects/TestAppWithWrapperProjectDependency

You will need to add a project-per-dependency.

If that doesn't unblock you, let's move this to https://github.com/dotnet/cli.

TheRealPiotrP commented Aug 3, 2016

@MV10 please see the pattern for wrapping loose dll's here:
https://github.com/dotnet/cli/tree/rel/1.0.0/TestAssets/TestProjects/TestAppWithWrapperProjectDependency

You will need to add a project-per-dependency.

If that doesn't unblock you, let's move this to https://github.com/dotnet/cli.

@pantonis

This comment has been minimized.

Show comment
Hide comment
@pantonis

pantonis Sep 13, 2016

Major blocking issue!!

pantonis commented Sep 13, 2016

Major blocking issue!!

@omuleanu

This comment has been minimized.

Show comment
Hide comment
@omuleanu

omuleanu Sep 21, 2016

so what is the latest solution ? do we just create nuget packages and add them to a local source ?

omuleanu commented Sep 21, 2016

so what is the latest solution ? do we just create nuget packages and add them to a local source ?

@jmcglory

This comment has been minimized.

Show comment
Hide comment
@jmcglory

jmcglory Sep 21, 2016

I would like to know if there is a fix for this yet

jmcglory commented Sep 21, 2016

I would like to know if there is a fix for this yet

@Tenmak

This comment has been minimized.

Show comment
Hide comment
@Tenmak

Tenmak Sep 21, 2016

There isn't and the only thing I managed to do was to setup a .net framework 451 dependency.

Tenmak commented Sep 21, 2016

There isn't and the only thing I managed to do was to setup a .net framework 451 dependency.

@omuleanu

This comment has been minimized.

Show comment
Hide comment
@omuleanu

omuleanu Sep 22, 2016

I actually need to reference .net core (.net standard 1.6) dlls, and I had to create .net package for this

omuleanu commented Sep 22, 2016

I actually need to reference .net core (.net standard 1.6) dlls, and I had to create .net package for this

@muratg

This comment has been minimized.

Show comment
Hide comment
@muratg

muratg Sep 22, 2016

Member

@piotrpMSFT Is there a dotnet/cli bug tracking this?

I'd like to move this discussion there, and close this bug on ASP.NET side.

Member

muratg commented Sep 22, 2016

@piotrpMSFT Is there a dotnet/cli bug tracking this?

I'd like to move this discussion there, and close this bug on ASP.NET side.

@andrey-moor

This comment has been minimized.

Show comment
Hide comment
@andrey-moor

andrey-moor Nov 4, 2016

Any updates on this?

andrey-moor commented Nov 4, 2016

Any updates on this?

@sohamchakravarty

This comment has been minimized.

Show comment
Hide comment
@sohamchakravarty

sohamchakravarty Jan 4, 2017

This is a huge blocker! Any updates on this yet?

sohamchakravarty commented Jan 4, 2017

This is a huge blocker! Any updates on this yet?

@gulbanana

This comment has been minimized.

Show comment
Hide comment
@gulbanana

gulbanana Jan 5, 2017

it works fine in vs2017 using csproj. it will not be implemented for vs2015 and project.json.

gulbanana commented Jan 5, 2017

it works fine in vs2017 using csproj. it will not be implemented for vs2015 and project.json.

@joebri

This comment has been minimized.

Show comment
Hide comment
@joebri

joebri Jan 28, 2017

I'm fairly new to NuGet so this might be 'old-hat' for some. But, for those who pursue the 'publish NuGet package' option I've just discovered that you can configure NuGet Manager to point to a local directory.

In Options...NuGet Package Manager...Package Sources, click on the + button (top right), and set the 'Source' to a local folder.

I have a step which creates NuGet packages and then copies them to this folder to be available for my .Net Core projects.

joebri commented Jan 28, 2017

I'm fairly new to NuGet so this might be 'old-hat' for some. But, for those who pursue the 'publish NuGet package' option I've just discovered that you can configure NuGet Manager to point to a local directory.

In Options...NuGet Package Manager...Package Sources, click on the + button (top right), and set the 'Source' to a local folder.

I have a step which creates NuGet packages and then copies them to this folder to be available for my .Net Core projects.

@krzysgl

This comment has been minimized.

Show comment
Hide comment
@krzysgl

krzysgl Jan 30, 2017

When adding a reference, use "Browse" tab, not the "Assemblies" tab. Then you can use unregistered libraries.

krzysgl commented Jan 30, 2017

When adding a reference, use "Browse" tab, not the "Assemblies" tab. Then you can use unregistered libraries.

@pappasa

This comment has been minimized.

Show comment
Hide comment
@pappasa

pappasa Feb 3, 2017

In VS2015 there is no "Browse" tab in the "Reference Manager" form:

visualstudio2015_2

How can I add references to .NET Framework 4.0 assemblies?

pappasa commented Feb 3, 2017

In VS2015 there is no "Browse" tab in the "Reference Manager" form:

visualstudio2015_2

How can I add references to .NET Framework 4.0 assemblies?

@michaelarner

This comment has been minimized.

Show comment
Hide comment
@michaelarner

michaelarner Feb 18, 2017

Just want to add my weight to the "this is really annoying" camp. I should be able to use basic xunit with a basic class library in core.

michaelarner commented Feb 18, 2017

Just want to add my weight to the "this is really annoying" camp. I should be able to use basic xunit with a basic class library in core.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Feb 18, 2017

Member

@michaelarner This is talking about assembly references not project references so the scenario you mention works.

Member

davidfowl commented Feb 18, 2017

@michaelarner This is talking about assembly references not project references so the scenario you mention works.

@michaelarner

This comment has been minimized.

Show comment
Hide comment
@michaelarner

michaelarner Feb 18, 2017

Thanks @davidfowl, sure doesn't work for me in VS2015 Update 3: I have a class library and an xunit project -- everything compiles and runs nicely, but I haven't been able to find anything that will let intellisense in my xunit tests see my class library..... ((an assembly OR project reference solution would be equally acceptable to me but neither seems to fly))

michaelarner commented Feb 18, 2017

Thanks @davidfowl, sure doesn't work for me in VS2015 Update 3: I have a class library and an xunit project -- everything compiles and runs nicely, but I haven't been able to find anything that will let intellisense in my xunit tests see my class library..... ((an assembly OR project reference solution would be equally acceptable to me but neither seems to fly))

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl Feb 19, 2017

Member

2 questions for ya:

  • Can you put the sample on github?
  • Are you using resharper?
Member

davidfowl commented Feb 19, 2017

2 questions for ya:

  • Can you put the sample on github?
  • Are you using resharper?
@ShreekantG

This comment has been minimized.

Show comment
Hide comment
@ShreekantG

ShreekantG Feb 23, 2017

I have DLL say "MyCustom.dll" located under my local machine. I want to refer the same in my .Net Core application. I am having below json file.

{
"version": "1.0.0-*",

"dependencies": {
"Microsoft.ApplicationInsights.AspNetCore": "2.0.0",
"Microsoft.AspNetCore.Mvc": "1.1.1",
"Microsoft.AspNetCore.Routing": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0",
"Microsoft.Extensions.Configuration.FileExtensions": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.Extensions.Logging.Debug": "1.1.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
},
"Price.Common": "1.0.0-*",//This is working as it is part of my main source.
"MyCustom": { "version": "1.1.13191.1" }//This is my new dll.
},

"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
],
"bin": {
"assembly": "D:/Clubcard/Shared-Libraries/Lib/API/MyCustom.dll"
}
}

}
}

Can any one help on how to reference the dll.

ShreekantG commented Feb 23, 2017

I have DLL say "MyCustom.dll" located under my local machine. I want to refer the same in my .Net Core application. I am having below json file.

{
"version": "1.0.0-*",

"dependencies": {
"Microsoft.ApplicationInsights.AspNetCore": "2.0.0",
"Microsoft.AspNetCore.Mvc": "1.1.1",
"Microsoft.AspNetCore.Routing": "1.1.0",
"Microsoft.AspNetCore.Server.IISIntegration": "1.1.0",
"Microsoft.AspNetCore.Server.Kestrel": "1.1.0",
"Microsoft.Extensions.Configuration.EnvironmentVariables": "1.1.0",
"Microsoft.Extensions.Configuration.FileExtensions": "1.1.0",
"Microsoft.Extensions.Configuration.Json": "1.1.0",
"Microsoft.Extensions.Logging": "1.1.0",
"Microsoft.Extensions.Logging.Console": "1.1.0",
"Microsoft.Extensions.Logging.Debug": "1.1.0",
"Microsoft.Extensions.Options.ConfigurationExtensions": "1.1.0",
"Microsoft.NETCore.App": {
"type": "platform",
"version": "1.0.1"
},
"Price.Common": "1.0.0-*",//This is working as it is part of my main source.
"MyCustom": { "version": "1.1.13191.1" }//This is my new dll.
},

"frameworks": {
"netcoreapp1.0": {
"imports": [
"dotnet5.6",
"portable-net45+win8"
],
"bin": {
"assembly": "D:/Clubcard/Shared-Libraries/Lib/API/MyCustom.dll"
}
}

}
}

Can any one help on how to reference the dll.

@michaelarner

This comment has been minimized.

Show comment
Hide comment
@michaelarner

michaelarner Feb 24, 2017

michaelarner commented Feb 24, 2017

@S-Raghav

This comment has been minimized.

Show comment
Hide comment
@S-Raghav

S-Raghav Mar 9, 2017

Is this issue fixed? I couldn't add Nunit to a .NET Core project from nuget since I got a "dependency Nunit >=3.6.1 could not be resolved" so I downloaded Nunit and tried adding references to the NetStandard1.6, 4.5 and portable DLLs. None of them worked

S-Raghav commented Mar 9, 2017

Is this issue fixed? I couldn't add Nunit to a .NET Core project from nuget since I got a "dependency Nunit >=3.6.1 could not be resolved" so I downloaded Nunit and tried adding references to the NetStandard1.6, 4.5 and portable DLLs. None of them worked

@S-Raghav

This comment has been minimized.

Show comment
Hide comment
@S-Raghav

S-Raghav Mar 9, 2017

I solved this for myself by making my test project a 4.6.1 Project instead of .NET core (NetStandard1.6), Nunit gets added. I am not able to add a project reference to netstandard1.6 project though. I have to manually add a reference by navigating to the project's Debug->netstandard1.6 folder and selecting the DLL

S-Raghav commented Mar 9, 2017

I solved this for myself by making my test project a 4.6.1 Project instead of .NET core (NetStandard1.6), Nunit gets added. I am not able to add a project reference to netstandard1.6 project though. I have to manually add a reference by navigating to the project's Debug->netstandard1.6 folder and selecting the DLL

@zoehart

This comment has been minimized.

Show comment
Hide comment
@zoehart

zoehart Mar 10, 2017

I have a solution that has an ASP.NET Core Web Application (.NET Framework) project, and two Class Library (.NET Core) projects. One of the class library projects needs to reference some legacy .NET Framework 4.6 assemblies. I am having the same problem as many of the people on this thread and, like them, am wondering if there is any resolution.
I saw references to moving this topic to dotnet/cli, but looked there and could not find it.
I saw some references in this thread to maybe needing to package my legacy assemblies in nuget packages and add them to my .NET Core class libraries that way. Is that the recommended workaround at this point?
I am using VS2015 Update 3 with Dot Net Core Tools Preview 2.

zoehart commented Mar 10, 2017

I have a solution that has an ASP.NET Core Web Application (.NET Framework) project, and two Class Library (.NET Core) projects. One of the class library projects needs to reference some legacy .NET Framework 4.6 assemblies. I am having the same problem as many of the people on this thread and, like them, am wondering if there is any resolution.
I saw references to moving this topic to dotnet/cli, but looked there and could not find it.
I saw some references in this thread to maybe needing to package my legacy assemblies in nuget packages and add them to my .NET Core class libraries that way. Is that the recommended workaround at this point?
I am using VS2015 Update 3 with Dot Net Core Tools Preview 2.

@zoehart

This comment has been minimized.

Show comment
Hide comment
@zoehart

zoehart Mar 10, 2017

I've gone ahead and created a NuGet package for my .NET Framework 4.6 assembly and have successfully (I think) installed it in my project. My project.json now looks like this:
{ "dependencies": { "NETStandard.Library": "1.6.0", "mycompany.myassembly.pkg": "4.6.0" }, "frameworks": { "netstandard1.6": { "imports": "dnxcore50" } }, "version": "1.0.0-*" }
VS2015 puts a squiggly red line under the "4.6.0" version of my package and complains that "The dependency mycompany.myassembly.pkg 4.6.0 does not support framework .NETStandard, Version=1.6." And I am not able to reference any namespace or class within my packaged assembly. Has anyone else gotten this far, seen this problem, and found a way around/past it?

zoehart commented Mar 10, 2017

I've gone ahead and created a NuGet package for my .NET Framework 4.6 assembly and have successfully (I think) installed it in my project. My project.json now looks like this:
{ "dependencies": { "NETStandard.Library": "1.6.0", "mycompany.myassembly.pkg": "4.6.0" }, "frameworks": { "netstandard1.6": { "imports": "dnxcore50" } }, "version": "1.0.0-*" }
VS2015 puts a squiggly red line under the "4.6.0" version of my package and complains that "The dependency mycompany.myassembly.pkg 4.6.0 does not support framework .NETStandard, Version=1.6." And I am not able to reference any namespace or class within my packaged assembly. Has anyone else gotten this far, seen this problem, and found a way around/past it?

@omuleanu

This comment has been minimized.

Show comment
Hide comment
@omuleanu

omuleanu Mar 10, 2017

I also created a local nuget package source on c:\mypackages for referencing my own .net core dlls

omuleanu commented Mar 10, 2017

I also created a local nuget package source on c:\mypackages for referencing my own .net core dlls

@StuartSmith

This comment has been minimized.

Show comment
Hide comment
@StuartSmith

StuartSmith Apr 8, 2017

I ran into this problem as well. see the following link

https://www.hanselman.com/blog/HowToReferenceAnExistingNETFrameworkProjectInAnASPNETCore10WebApp.aspx

Basically you have to make the portable library target .net 4.6 if not the references do not work and compile time problems abound.

StuartSmith commented Apr 8, 2017

I ran into this problem as well. see the following link

https://www.hanselman.com/blog/HowToReferenceAnExistingNETFrameworkProjectInAnASPNETCore10WebApp.aspx

Basically you have to make the portable library target .net 4.6 if not the references do not work and compile time problems abound.

@aspnet-hello

This comment has been minimized.

Show comment
Hide comment
@aspnet-hello

aspnet-hello Dec 30, 2017

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.

aspnet-hello commented Dec 30, 2017

This issue is being closed because it has not been updated in 3 months.

We apologize if this causes any inconvenience. We ask that if you are still encountering this issue, please log a new issue with updated information and we will investigate.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment