Closed weshaggard closed 6 years ago
In case it is interesting here is the ResolveAssemblyReferences output from the log.
I particularly found this part interesting that RAR saw the missing dependency but didn't bubble it up as an issue.
2> Dependency "Microsoft.Win32.Primitives, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". (TaskId:73)
2> Could not resolve this reference. Could not locate the assembly "Microsoft.Win32.Primitives, Version=4.0.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. (TaskId:73)
I think the issue here it's that the desktop project is not in PackageReference mode, so the reference don't flow.
This is a bad experience, we've had several other issues filled for this.
@dsplaisted Not sure about that, I saw it in a PackageRef project here: https://github.com/onovotny/microsoft-authentication-library-for-dotnet/blob/b437210265d4c5fa33729c0580b5ce1c2c4c54e6/samples/DesktopTestApp/DesktopTestApp.csproj
https://github.com/dotnet/corefx/issues/14565#issuecomment-280880858
For anyone that might still be hitting this you can workaround it by explicitly making the .NET Framework project a ProjectReference based project by setting the following property in the project:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
There is also a good change you will need auto-bindingredirects as well so make sure that is set in your project:
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
weshaggard, can you elaborate on the workaround? Where should I put the text below (which file)? In which project, the one targeting the .NET Standard or the one referencing the .Net Standard project (the .Net Framework project)?
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
In the .NET Framework project that is consuming the .NET Standard library. Note that if you have a packages.config file with nuget packages installed you will need to reinstall them as that property opts you into the PackageReference model instead of the packages.config model (see https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files for some more information).
@weshaggard - does PackageReference just happen to work with .NET Framework projects? The doc you linked suggests it's not supported:
At present, package references are supported in Visual Studio 2017 only, for .NET Core projects, .NET Standard projects, and UWP projects targeting Windows 10 Build 15063 (Creators Update).
I've been using <PackageReference>
in .NET Framework new-style csproj since March and in Windows Forms old-style csproj since April. Definitely agree that the documentation needs to be improved.
cc @AlexGhiondea fyi.
My .net framework 4.7 project already has the package references in the project file. I also tried adding the
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
and
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
But I'm still running into the FileNotFound exception as soon as I access code from the .net standards class library. I'm missing the references the class library depends on.
BTW, what I'm noticing is that the exception I'm getting of for System.Data.Common version 4.1.0.0. If I look at the .net standard library, it uses the MySqlConnector nuget package, which has a dependency on System.Data.Common version 4.3.0.0. I can not find anything that wants to use version 4.1.0.0
If I use nuget to add this package to the .net framework app, then this is fixed, but it throws it for another dependency in the ,net standard class library.
@weshaggard can you help with the latest info above?
I'm still having this issue with VS15.3 and netstandard 2.0 I've also reported this to the visual studio team now: System.IO.FileNotFoundException when referencing netstandard library project in classic project
You could try upvoting it there...
@weshaggard
@remcolam I pulled down your same solution from your reported issue and I did repro the issue but I was able to fix it by adding <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
in the ClassicConsole csproj. After adding that the dependencies correctly flowed from the NetStandard20Lib ProjectReference. Can you please try that to ensure it works for you?
@weshaggard I was under the impression that was needed when switching from packages.config to project references, and I created these projects from the beginning with project references...
But I will try it and let you know.
It still seems to me visual studio should be making sure the dependencies flow through correctly, so I'll keep the issue open at visual studio community... 😉
@weshaggard I was under the impression that was needed when switching from packages.config to project references, and I created these projects from the beginning with project references...
Yes that us what it does but the package dependencies don't currently flow correctly in the packages.config world only in the new ProjectReference world.
It still seems to me visual studio should be making sure the dependencies flow through correctly, so I'll keep the issue open at visual studio community
I completely agree this is an issue that should be address which is why I opened this issue to track it as well. I'm only a consumer of these tools and so I would also like this fixed and what I suggested here is merely a workaround.
Adding
`
` to the project file for the classic project made it indeed work. Still strange , because this was already the format for the project... Oh well... Thanks for the help
Why is this workaround necessary? Why is the behavior not defaulted to copying needed dependencies to the build directory? Under what scenario would I rather NOT have them copied? FYI this is still occurring in Visual Studio 2017 and .NET Standard 2.0.
@babelshift SDK projects don't copy dependencies to the output directory because the output can be different depending on what the TFM of the consuming project is. Consider the following:
A (project) (net461) B (project) (netstandard 2.0) Newtonsoft.Json (package) (net45, ns1.1)
A -> B -> Newtonsoft.Json
For this dependency graph, the version of Newtonsoft.Json copied to A's output folder is net45, the version copied into the output of B is ns1.1
@davidfowl So what's the long term solution here? Using the PackageReference
solution? Googling about this problem reveals a lot of confusion around this behavior, and the documentation could be more clear (unless I'm missing some important docs).
Please help me understand a bit more.
Console App (.NET 4.6.1) -> Class Library 1 (.NET 4.6.1) -> Class Library 2 (.NET Standard 2.0) -> NuGet Package (Newtonsoft.Json)
After build, the Console App's bin directory contains:
This will fail at runtime because Class Library 2.dll and Newtonsoft.Json.dll are non-existent.
The Visual Studio tooling seems to offer no assistance to remedy this unless I'm missing something.
@davidfowl So what's the long term solution here? Using the PackageReference solution? Googling about this problem reveals a lot of confusion around this behavior, and the documentation could be more clear (unless I'm missing some important docs).
Yes, that's the long term solution.
This will fail at runtime because Class Library 2.dll and Newtonsoft.Json.dll are non-existent.
Is Console App (.NET 4.6.1) using package reference? If, not then this is a known issue. We should have blocked that reference but we don't and it ends up breaking at runtime.
Is this just for package references? I was directed here from the same issue regarding project references. I have the netstandard2.0 project in the same solution and I'm trying to reference from .net framework console app and nothing resolves. I added in the package restore style but it doesn't seem to work for me. Repro from scratch here: https://github.com/dasjestyr/netstandard_ref_error
Using VS2017.3.3. <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
did not work for me. It seems that the solution will build, but intellisense is still bleeding everywhere.
I'm using VS2017 15.3.3 and .NET Core 2.0.0 SDK. My (simplified) solution consists of following projects:
Using <RestoreProjectStyle>PackageReference</RestoreProjectStyle>
fixed the problem in B. But when I applied it to C, suddenly all tests disappeared from Test Explorer window. To fix this issue, I had to upgrade test adapters and test framework via nuget as described here (in case somebody has the same problem).
Is this intended behavior of package reference or a bug?
Disregard my comment with the repro link. I think it was resharper... sigh. I updated resharper and things started working.
Dealing with a similar issue here. I have a simple .net standard 1.4 library that is tested using nunit3. Running on 4.6.1 I get this when running tests that use features from the library dealing with files:
System.IO.FileNotFoundException:
Could not load file or assembly 'System.IO.FileSystem, Version=4.0.1.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.
The actual Version of System.IO.FileSystem I use is 4.3.0. I tried various workarounds from a few github issues but none of them seem to work. The only thing I found to work was to switch the library to .net standard 2.0.
Have you tried adding a net461 target to the standard library? That fixed it for me.
The ideal scenario is that the class library is netstandard. and the test project targets net***;netcoreapp*.*
or something like that. If you make the class library target both netstandard1.4
and net461
, you won't be truly testing the netstandard1.4
dll because the test project will ignore it and pick up the net461
dll.
Still got the problem in VS2017 15.5 , .NET Framework 4.6.1 and Core 2.0 Standard 1.4
Yet solved by `
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
`
This works for project references for the project in the same solution. If I try to add a reference to an external project .dll from a project in another solution, that project's dependencies don't get copied into the output folder of the referring project.
I think I'm seeing the same thing with a JavaScript UWP app, as the default VS template uses package.json
for those projects.
Referencing a .NET Standard 1.4 component using ProjectReference
through a Windows Runtime Component.
@jnm2 I believe what you want to do is have the test project for a netstandard library actually target only netcoreapp. Then it will only pick up the netstandard version of the class library. I don't really see the point of having the test project target both net*** and netcoreapp. So basically reverse of what you're saying.
There is an argument to be made for testing a netstandard1.4 class library against net47;netcoreapp1.1;netcoreapp2.0 since the behaviors are different. But that's very difficult to do if the class library also targets net or netcoreapp, with current tooling. There are discussions other places about making this easier by allowing tests to target netstandard1.4 and configuring the test runner to execute the same test dll against multiple runtimes and versions.
My point is only that you should not target the class library as netstandard1.4;net461 unless your test project is netcoreapp.;net461 or else you'll be shipping an untested unique dll and that's a very bad thing to do.
@weshaggard This solution didn't work for me. I've added the two configuration lines in the .NET Framework project and rebuilt the whole solution. Still the .NET Standard package upon which the .NET Standard project depends isn't flown to the .NET Framework project's output folder
@godrose any chance you could post a simple repo solution somewhere? I do expect you are hitting the limitations outlined in this issue but I can hopefully help you find the right workaround.
I have an actual not-so-simple repro solution you can clone.
DebugWithFake
build configurationHow to reproduce the issue:
Client.Launcher
project.csproj
AutoMapper
)Object reference is not set to an instance of an object
AutoMapper
is not thereIf these repo steps are too much I'll try to add a lighter repo tomorrow.
@godrose interestingly enough I got just the opposite results from you. With the simple clone at commit https://github.com/LogoFX/Samples.Specifications/commit/437cf1069b163c55abfd8867c2c56ee878405433 I get the "object reference is not set to an instance of an object" error. However if I go back one commit to https://github.com/LogoFX/Samples.Specifications/commit/8603d82b723debb0efc5fe22d740d6f3d2958105 and do a full clean (i.e. close VS and run git clean -xdf) then I can successfully login and see the grid of data. Can you please make sure you are cleaning, not only the bin folder but the obj folders as well, ideally a full git clean -xdf.
While looking around in the solution I noticed you have a lot of other projects which use packages.config files. It is generally not advised to mix and match solutions with some projects using packages.config and other projects using ProjectReference. The two models don't play well together as the packages.config projects do not correctly flow dependencies from referenced projects/packages.
Thanks. I will check this. I'm just trying out this approach to see if it fixes the issue
On 21 Feb 2018 20:09, "Wes Haggard" notifications@github.com wrote:
@godrose https://github.com/godrose interestingly enough I got just the opposite results from you. With the simple clone at commit LogoFX/Samples.Specifications@437cf10 https://github.com/LogoFX/Samples.Specifications/commit/437cf1069b163c55abfd8867c2c56ee878405433 I get the "object reference is not set to an instance of an object" error. However if I go back one commit to LogoFX/Samples.Specifications@8603d82 https://github.com/LogoFX/Samples.Specifications/commit/8603d82b723debb0efc5fe22d740d6f3d2958105 and do a full clean (i.e. close VS and run git clean -xdf) then I can successfully login and see the grid of data. Can you please make sure you are cleaning, not only the bin folder but the obj folders as well, ideally a full git clean -xdf.
While looking around in the solution I noticed you have a lot of other projects which use packages.config files. It is generally not advised to mix and match solutions with some projects using packages.config and other projects using ProjectReference. The two models don't play well together as the packages.config projects do not correctly flow dependencies from referenced projects/packages.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/dotnet/sdk/issues/901#issuecomment-367417669, or mute the thread https://github.com/notifications/unsubscribe-auth/AHbkIxE1fewGpp2tiotemxgssSsIFU9cks5tXFvjgaJpZM4MI9nG .
@weshaggard Interestingly enough I managed to login successfully and see the grid after a full clean. I will convert the whole solution to this approach and see whether it works in all scenarios. Thanks a lot!
Not a question, but an observation and approach we're depending upon....
We are also experiencing some issues and have a concern about addressing the reverse transitive dependency issue for reflection loaded IoC patterns....
exe -> A <- B -> C exe is never aware of the existence of B or C A reflection loads B which has compile time dependency on C (say Npgsql.dll) Recompiling the exe is NOT an option (different vendors and runtime injection of capabilities)
Also, there are multiple items loaded this way exe -> A <- B -> C(v1) ^--- D -> C(v2) As long as C(v2) is capable of supporting C(v1) surface area, we realize C(v2) at runtime for both B and D, which are reflection loaded by A again with no knowledge from the exe.
this has been working fine in purely net 4.6.1, but now with netstandard, we have been having different issues on production machines and dev machines. We can work around the issue on dev machines (Win 10) by adding version bindings in the .exe.config (not ideal) on the dev machines, but have "odd" issues we still haven't resolved on prod machines (not Win 10).
I have experienced this same issue, but the workaround didn't seem to resolve the problem in my case. Here are some steps to reproduce a simple version of what I'm seeing:
using System.Data.SqlClient;
namespace ClassLibrary1 { public class Class1 { public Class1() { var connection = new SqlConnection(""); } } }
6. At the end of the Global.asax file in the web application project root, add the following line:
var c = new ClassLibrary1.Class1();
7. Run the web application project. It crashes on startup at the line above with the following error:
> System.IO.FileNotFoundException: 'Could not load file or assembly 'System.Data.SqlClient, Version=4.4.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified.'
Not sure if it's something specifically to do with how web application projects resolve dependencies, but adding the `RestoreProjectStyle` and `AutoGenerateBindingRedirects` to the project file didn't fix the issue.
The only way I could work around the problem was to install all the dependencies in both projects.
I encountered this problem today, and it happened to be with the exact same System.Data.SqlClient.dll that @greg84 ran into problems with.
I have uploaded a simple repro like @greg84 described here: https://github.com/dsteinweg/dotnet-sdk-issue-901
There are two ways to fix this:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
Can we just don't break .NET Framework projects introducing half done (like .NET Core) style features?
I've encountered this issue today when I deploy to my Azure App Service. We're running Full Framework 4.7 and one of our libraries is responsible for rendering Razor views to string for export. It leverages Microsoft.AspNetCore.Mvc.ViewFeatures
. The code for this is pretty standard:
`
public async Task
using (var sw = new StringWriter())
{
var viewResult = _razorViewEngine.FindView(actionContext, viewName, false);
if (viewResult.View == null)
{
throw new ArgumentNullException($"{viewName} does not match any available view");
}
var viewDictionary = new ViewDataDictionary(new EmptyModelMetadataProvider(), new ModelStateDictionary())
{
Model = model
};
var viewContext = new ViewContext(
actionContext,
viewResult.View,
viewDictionary,
new TempDataDictionary(actionContext.HttpContext, _tempDataProvider),
sw,
new HtmlHelperOptions()
);
try
{
await viewResult.View.RenderAsync(viewContext);
}
catch (Exception e)
{
_logger.Error(e, "An error occurred while rendering HTML from Razor templates.");
return String.Empty;
}
return sw.ToString();
}
}
It works perfectly fine locally, but when I deploy it to our app service, I get the following error when
await viewResult.View.RenderAsync(viewContext)` is invoked:
System.InvalidOperationException: Cannot find reference assembly 'Microsoft.Win32.Primitives.dll' file for package Microsoft.Win32.Primitives.Reference at Microsoft.Extensions.DependencyModel.Resolution.ReferenceAssemblyPathResolver.TryResolveAssemblyPaths(CompilationLibrary library, List
1 assemblies)
at Microsoft.Extensions.DependencyModel.Resolution.CompositeCompilationAssemblyResolver.TryResolveAssemblyPaths(CompilationLibrary library, List1 assemblies) at Microsoft.Extensions.DependencyModel.CompilationLibrary.ResolveReferencePaths(ICompilationAssemblyResolver resolver, List
1 assemblies)
at Microsoft.Extensions.DependencyModel.CompilationLibrary.ResolveReferencePaths()
at Microsoft.AspNetCore.Mvc.ApplicationParts.AssemblyPart.<>c.2.MoveNext() at Microsoft.AspNetCore.Mvc.Razor.Compilation.MetadataReferenceFeatureProvider.PopulateFeature(IEnumerable
1 parts, MetadataReferenceFeature feature)
at Microsoft.AspNetCore.Mvc.ApplicationParts.ApplicationPartManager.PopulateFeature[TFeature](TFeature feature)
at Microsoft.AspNetCore.Mvc.Razor.Internal.DefaultRazorReferenceManager.GetCompilationReferences()
at System.Threading.LazyInitializer.EnsureInitializedCore[T](T& target, Boolean& initialized, Object& syncLock, Func1 valueFactory) at Microsoft.AspNetCore.Mvc.Razor.Internal.DefaultRazorReferenceManager.get_CompilationReferences() at Microsoft.AspNetCore.Mvc.Razor.Internal.LazyMetadataReferenceFeature.get_References() at Microsoft.CodeAnalysis.Razor.CompilationTagHelperFeature.GetDescriptors() at Microsoft.AspNetCore.Razor.Language.DefaultRazorTagHelperBinderPhase.ExecuteCore(RazorCodeDocument codeDocument) at Microsoft.AspNetCore.Razor.Language.RazorEnginePhaseBase.Execute(RazorCodeDocument codeDocument) at Microsoft.AspNetCore.Razor.Language.DefaultRazorEngine.Process(RazorCodeDocument document) at Microsoft.AspNetCore.Razor.Language.DefaultRazorProjectEngine.ProcessCore(RazorCodeDocument codeDocument) at Microsoft.AspNetCore.Razor.Language.RazorProjectEngine.Process(RazorProjectItem projectItem) at Microsoft.AspNetCore.Mvc.Razor.Internal.RazorViewCompiler.CompileAndEmit(String relativePath) at Microsoft.AspNetCore.Mvc.Razor.Internal.RazorViewCompiler.OnCacheMiss(String normalizedPath) --- End of stack trace from previous location where exception was thrown --- at System.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task) at System.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccessAndDebuggerNotification(Task task) at Microsoft.AspNetCore.Mvc.Razor.Internal.DefaultRazorPageFactoryProvider.CreateFactory(String relativePath) at Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine.CreateCacheResult(HashSet
1 expirationTokens, String relativePath, Boolean isMainPage)
at Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine.OnCacheMiss(ViewLocationExpanderContext expanderContext, ViewLocationCacheKey cacheKey)
at Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine.LocatePageFromViewLocations(ActionContext actionContext, String pageName, Boolean isMainPage)
at Microsoft.AspNetCore.Mvc.Razor.RazorViewEngine.FindView(ActionContext context, String viewName, Boolean isMainPage)
at Microsoft.AspNetCore.Mvc.ViewEngines.CompositeViewEngine.FindView(ActionContext context, String viewName, Boolean isMainPage)
at Microsoft.AspNetCore.Mvc.ViewComponents.ViewViewComponentResult.
that's really a bad experience
The workaround isn't working for me. The scenario might be slightly different:
If I run msbuild
with -verbosity:detailed
, I can see:
Could not resolve this reference. Could not locate the assembly "...blah...". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
... but this does not appear as a warning/error in the Visual Studio build output.
My NETFramework project has the suggested properties in the csproj file:
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
I can solve the problem by adding a direct reference to the missing assembly in either my NETStandard class library or my NETFramework project, but it seems like a possible bug somewhere.
Copied from https://github.com/dotnet/corefx/issues/14565.
From @jnm2
Am I doing something incorrect? I was not sure if this is the same problem as the other problems I've had with netstandard. Just by luck, every single one of my forays into netstandard have failed with this same type of issue. I have great confidence that it's just me and these will all be fixed by VS2017's RTM.
Create a new .NET Standard library targeting netstandard1.3. Create a static method Class1.DoWork() that throws new Win32Exception(). Add a .NET Framework console app targeting net462 In Program.cs, call Class1.DoWork() and add a reference to the library project. Run the console app and get:
Is this a binding redirect issue or something? I hope this isn't the way things are intended to be? As long as this type of error exists, can you please maintain a netstandard troubleshooting document with step-by-step guidance for the workaround?
I would hope that scenarios like this would be covered by integration tests.
https://github.com/jnm2/misc-codesamples/raw/master/Bug%20reports/.NET/NetStandard%20Win32Exception%20causes%20file%20not%20found.zip
From @weshaggard
Looking at his solution the issue stems from the fact that the ProjectReference from the DesktopConsoleApp to the NETStandardLibrary project isn't flowing the dependencies correctly so it isn't seeing Microsoft.Win32.Primitives at all. It isn't even an issue with binding redirects in this case it is just a missing dependency. To workaround it you can add a reference to the Microsoft.Win32.Primitives nuget package to the DesktopConsoleApp. However this sounds like a tooling issue where dependencies aren't flowing.