Accessing resources from non-DNX assembly Cause Exception System.IO.FileNotFoundException

[kirthik]

Moving aspnet/Localization#123 From @luchen1021 to this repo
Beta 8 load resource assembly cause exception System.IO.FileNotFoundException. The resource assembly is defined in legacy .NET class library, not DNX class library. The same solution works for Beta 7 but fails when using Beta 8.
Beta 8 Solution
https://github.com/luchen1021/AspNet5Beta8Resource.git
https://github.com/luchen1021/AspNet5Beta8Resource
Beta 7 Solution
https://github.com/luchen1021/AspNet5Beta7Resource.git
https://github.com/luchen1021/AspNet5Beta7Resource

Change project reference to binary reference for Legacy Library and Legacy Resource Library.
https://github.com/luchen1021/AspNet5Beta8ResourceBinaryReference.git
https://github.com/luchen1021/AspNet5Beta8ResourceBinaryReference
Running in Visual Studio 2015 with IISExpress still get the same exception as shown in top comment.
Publish works fine in binary reference approach. After deploying the published output to IIS (not IIS express), it works fine without any exception.

Exception Detail:
System.IO.FileNotFoundException: {"Could not find file 'AspNet5Beta8Resource.LegacyResources.resources'.":null}
Data: {System.Collections.ListDictionaryInternal}
FileName: null
FusionLog: null
HResult: -2147024894
HelpLink: null
IPForWatsonBuckets: {1858045768}
InnerException: null
IsTransient: false
Message: "Could not find file 'AspNet5Beta8Resource.LegacyResources.resources'."
RemoteStackTrace: null
Source: "mscorlib"
StackTrace: " at System.Reflection.RuntimeAssembly.InternalGetSatelliteAssembly(String name, CultureInfo culture, Version version, Boolean throwOnFileNotFound, StackCrawlMark& stackMark)
at System.Resources.ManifestBasedResourceGroveler.GetSatelliteAssembly(CultureInfo lookForCulture, StackCrawlMark& stackMark)
at System.Resources.ManifestBasedResourceGroveler.GrovelForResourceSet(CultureInfo culture, Dictionary`2 localResourceSets, Boolean tryParents, Boolean createIfNotExists, StackCrawlMark& stackMark)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo requestedCulture, Boolean createIfNotExists, Boolean tryParents, StackCrawlMark& stackMark)
at System.Resources.ResourceManager.InternalGetResourceSet(CultureInfo culture, Boolean createIfNotExists, Boolean tryParents)
at System.Resources.ResourceManager.GetString(String name, CultureInfo culture)
at AspNet5Beta8Resource.LegacyResources.Properties.Resources.get_Title() in D:\Project\GitHub\AspNe
t5Beta8Resource\AspNet5Beta8Resource.LegacyResources\Properties\Resources.Designer.cs:line 68
at AspNet5Beta8Resource.LegacyLibrary.LegacyClass.GetTitle() in D:\Project\GitHub\AspNet5Beta8Resource\AspNet5Beta8Resource.LegacyLibrary\LegacyClass.cs:line 14
at AspNet5Beta8Resource.DnxWebHost.Controllers.ValuesController.Get() in D:\Project\GitHub\AspNet5Beta8Resource\AspNet5Beta8Resource.DnxWebHost\Controllers\ValuesController.cs:line 21"
TargetSite: {System.Reflection.RuntimeAssembly InternalGetSatelliteAssembly(System.String, System.Globalization.CultureInfo, System.Version, Boolean, System.Threading.StackCrawlMark ByRef)}
WatsonBuckets: null
_HResult: -2147024894
_className: null
_data: {System.Collections.ListDictionaryInternal}
_dynamicMethods: null
_exceptionMethod: {System.Reflection.RuntimeAssembly InternalGetSatelliteAssembly(System.String, System.Globalization.CultureInfo, System.Version, Boolean, System.Threading.StackCrawlMark ByRef)}
_exceptionMethodString: null
_fileName: null
_fusionLog: null
_helpURL: null
_innerException: null
_ipForWatsonBuckets: {1858045768}
_maybeFullPath: null
_message: "Could not find file 'AspNet5Beta8Resource.LegacyResources.resources'."
_remoteStackIndex: 0
_remoteStackTraceString: null
_safeSerializationManager: {System.Runtime.Serialization.SafeSerializationManager}
_source: "mscorlib"
_stackTrace: {sbyte[192]}
_stackTraceString: null
_watsonBuckets: null
_xcode: -532462766

_xptrs: {0}

[joplaal]

This is a very important issue, since it prevents to use very popular libraries, like Entity Framework 6 from DNX projects, when current thread culture is other than invariant culture.

[luchen1021]

Is there any update on this issue? Will there be a fix for this issue in RC1?

Thank you!

[leak]

This issue is still unresolved on RC1.

This problem basically prevents you from using Microsoft.AspNet.Localization because as soon as you reference a 3rd library and the processing thread's culture is not Invariant you will get a FileNotFoundException for non-existing resources.

Any chance this issue could get a higher priority?

[mightyzot]

This is an extremely important issue for us as it prevents us from using non-dnx libraries that we've spent several years creating. Please don't let this one go unfixed.

[joerglang]

Thought that RC means Release Candidate, meaning it is considered to be soon released and that developer can start implementing solutions.
But something "Standard" as this still does not work is a major obstacle and needs to be fixed, or is Microsoft believing that everyone is creating everything from scratch?

[muratg]

Folks, DNX is being retired in the next release i.e. we won't be releasing another version of DNX with ASP.NET Core. The new command line experience will be through dotnet CLI (https://github.com/dotnet/cli). I recommend trying it out.

[chosenek]

Any plans on fixing this? It is not fixed in latest RC2 too.

I dont get it how such a serious stuff can be around for so long time without a fix.

[davidfowl]

I dont get it how such a serious stuff can be around for so long time without a fix.

It means there's other more serious stuff to get to first. As @muratg said, DNX is being retired and we're busy working on making the dotnet CLI command line tools work for the basic flow (dev, test, debug, publish). Once the basics work, then we'll get to xproj -> csproj integration again, once that works, then we'll handle xproj -> csproj with resources.

[chosenek]

Ok, that I understand. What I don't understand is that MS gave ASP.NET 5 a "Go Live" license for a production deployment even with such a drawbacks? Very strange.

Any possible workarounds?

[davidfowl]

Not that I'm aware of, it probably requires some horrific code.

[chosenek]

Is this related only to some specific function, which can be removed/avoided? "Leak" mentioned above that it prevent from using Localization. I have removed any localization from our code and still having the same error while calling 3rd party library function.

In other words - is there ANYTHING I can do to get rid of this error while still using the 3rd party library, which is essential for our project?

Please, do not answer that there is nothing I can do.

[davidfowl]

This issue is specifically to do with using resource from a csproj project reference. Is that your scenario? Nobody has dug into a workaround because most if the infrastructure is changing and the issue will fix itself when we move to the cli.

As for a workaround, if you can provide a sample I'll see if I can figure something out. I'm assuming you're using rc1 bits right?

[mightyzot]

@davidfowl, this issue appears to be caused by referencing assemblies created from csproj projects. We need to be able to reference those assemblies, of course, because they represent years of research and development and they do and will support both future asp.net projects as well as console apps, windows apps, etc. If you're saying that this will be resolved prior to release of asp.net 5 mvc 6, then I think that's fine. If not, then it needs to be addressed prior to release.

@chosenek, there is a workaround, but it requires you to rebuild the older project with a slight modification to the auto-generated resource files. I don't have that on-hand right at the moment. I'll look it up tomorrow and post here, referencing the author of that workaround.

Essentially, the workaround is to load the assembly and pass GetName() for the assembly name containing the resources. By default, I believe the auto-generated code passes the name of the currently executing assembly, which is what fails.

Amended: @davidfowl - those are not project references, of course, they are direct references to the assemblies.

[joerglang]

@davidfowl I am on the same line as chosenek regarding the "GoLive" license. I mean it is labled as "Release Candidate" which means according to Wikipedia that the product has the potential to be the final product if no serious bugs emerge. This does not really fit together with removing dnx and replacing it with cli which is kind of a huge design change late in the cycle...

I'm sure there are a ton of good reasons for all this. But having started to use RC1 for two weeks now, I ran into several problems that hinder to see it as a "Go Live" product.

[chosenek]

@davidfowl I am not sure if the example will help here, but we are using an Interactive Inteligence (call center stuff) and I am stuck at the very beginning while establishing connection with server.
Example can be found here: https://developer.inin.com/documentation/documents/icelib/40/webhelp/html/61196512-59bd-fb1e-20f0-96a5dddb6bc0.htm
The error is thrown on the last line there, using session.Connect(
I can even provide the Dlls, if you think it might help.

David, let me ask differently. We have been planning on using ASP.NET 5 for upcoming, bigger, project. I have convinced everyone that this is a way to go. Now with these changes planned - do you think its better idea to avoid ASP.NET 5 until final version is out? We are still at the stage where change is possible.

@mightyzot An example would definitely help. But if you mean by the 'older project', the assembly which causing this issue, then I am afraid we don't have a access to the source code. Its 3rd party application.

What I have also noticed is that while referencing required assemblies in non asp.net 5 projects, all assemblies which are dependency to the referenced ones are copied to the project output automatically. In asp.net 5, I have to add all of them one by one as a direct reference in the project.

Everyone: Isn't there a way to use a reflection to instantiate the assembly or just call the method of the assembly that causing the problem, with some reflection-like tweaks?

[jelster]

@davidfowl

This issue is specifically to do with using resource from a csproj project reference. Is that your scenario?

This issue is not limited to surfacing when attempting to load/use resources in an embedded assembly from a csproj project reference. I have a solid repro for this when referencing an already-built DLL containing an embedded resource.

Nobody has dug into a workaround because most if the infrastructure is changing and the issue will fix itself when we move to the cli.

So is it the case that all ISV's and 3rd party vendors will need to change the way their products get built simply in order for their customers to be able to reference their assemblies? I'm almost certainly misunderstanding something here, any clarification would be appreciated.

I've confirmed the issue on CRL RC1 Update 1 and on 1.0.0-rc2-16357 in a simple console app referencing the assemblies, which were built against .NET 4.5 using the "traditional" project/build system

[crokusek]

There is a workaround posted in
3023 by
luchen1021 commented on Oct 20, 2015

But it does require access/modification to the Resources.Designer.cs

[rubenprins]

@crokusek, Resources.Designer.cs will be rewritten by Visual Studio the moment you edit any resource item. So this workaround will only work when you stop maintaining your resources, or when you constantly roll back any change VS makes to that particular line.

It's a highly brittle workaround until the CLI team fixes the assembly resolution problems for the venerable ResourceManager class.

@davidfowl, you mentioned

the issue will fix itself when we move to the cli.

There are several issues open on this bug, and they all point back to this one, but no indication whatsoever whether this is even being investigated. And since this showstopper is labelled as Backlog (as is https://github.com/dotnet/cli/issues/550), I can only assume it will not be fixed for v1; but I'd love to be corrected.

[crokusek]

A better workaround--its reflection man to the rescue!!.

Usage (e.g. place in Startup.cs):

    PatchResourcesForDnx(typeof(YourNamespace.LocalizableResources.Resource));

    private void PatchResourcesForDnx(Type resourceType)
    {
        // The resources are not retrievable by the standard compiled name in Resource.Designer.cs
        // https://github.com/aspnet/dnx/issues/3023    // workaround by luchen1021 commented on Oct 20, 2015
        // https://github.com/aspnet/dnx/issues/3047    // resource bug, this improvement, crokusek
        // http://stackoverflow.com/questions/2330026   // overwrite static member

        // Overwrite the private static member "resourceMan" using reflection
        //
        FieldInfo fieldInfo = resourceType.GetField("resourceMan", BindingFlags.Static | BindingFlags.NonPublic);
        fieldInfo.SetValue(null, new ResourceManager(resourceType.FullName, Assembly.Load(resourceType.Assembly.GetName())));            
    }      

[musabsudan]

We have made a mistake and adopted Asp.Net Core earlier than we should, the go live license deceived us.

The go live seems to be for a Hello World apps only. You've promised us the moon guys and here we are.

[patrikwlund]

@musabsudan We upgraded from Beta7 to RC2 (since Beta8+ didn't work), and it works just fine with EF6 migrations in a csproj-project. I also tried adding a custom resource file to the csproj-project, and that is also accessible from the .Net Core project.

So we're not seeing any problems with this right now. What's the use-case that doesn't work for you?

[mightyzot]

The problem was with consuming resources in libraries that were built for other projects, libraries that have been in production and likely couldn’t be recompiled. Adding resources directly to the project was not an issue (in case that is how you tested this.)

From: patrikwlund [mailto:notifications@github.com]
Sent: Thursday, June 2, 2016 4:40 AM
To: aspnet/dnx dnx@noreply.github.com
Cc: mightyzot markus.pope@softwareforsimon.com; Mention mention@noreply.github.com
Subject: Re: [aspnet/dnx] Accessing resources from non-DNX assembly Cause Exception System.IO.FileNotFoundException (#3047)

@musabsudan https://github.com/musabsudan We upgraded from Beta7 to RC2 (since Beta8+ didn't work), and it works just fine with EF6 migrations in a csproj-project. I also tried adding a custom resource file to the csproj-project, and that is also accessible from the .Net Core project.

So we're not seeing any problems with this right now. What's the use-case that doesn't work for you?

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub #3047 (comment) , or mute the thread https://github.com/notifications/unsubscribe/AGCKHGMpzktjASoQy1p0B_-hsX3wnc-eks5qHqTdgaJpZM4GT9gz . https://github.com/notifications/beacon/AGCKHLU0oWI9GxaOdd13R5qUdK1YqKtQks5qHqTdgaJpZM4GT9gz.gif

[musabsudan]

@patrikwlund I have been redirected to here from other places, my main issue was in the localization and the use of resource files.

Globalization and localization

Currently, resource files are not read when the project is run from Visual Studio. See this issue for more information. Until the issue with Visual Studio is addressed, you can test the project by running it from the command line.

No worries I already decided to stop any serious development with Asp.Net Core till you guys figure the basic workflow and decide on something. But today one of my team members asked for help.