The component does not have a resource identified by the URI

[sofu456]

namespace WpfApp2 { ///

/// Interaction logic for MainWindow.xaml ///

public partial class MainWindow : Window { public static int i = 0; public static string csscript = @" using WpfApp2; class ScriptCondition { public ScriptCondition() { //new MainWindow().Show(); } } "; public MainWindow() { try { InitializeComponent(); } catch { } Loaded += MainWindow_Loaded; }

    private void MainWindow_Loaded(object sender, RoutedEventArgs e)
    {
        CSScript.Evaluator.LoadCode(csscript);
        //var eval = CSScript.Evaluator.ReferenceDomainAssemblies(DomainAssemblies.AllStaticNonGAC);
        //Assembly compilecode = eval.CompileCode(csscript);
        //var ps = compilecode.GetType("css_root+ScriptCondition");
        //var obj = compilecode.CreateInstance("css_root+ScriptCondition");
        if (i++ == 0) new MainWindow().ShowDialog();

    }
}

}

[sofu456]

use the cssript in wpf framework.it is easy encounter with this promblem.I have no idea to solve it.

[oleg-shilo]

The WPF host sample shows how to execute simple scripts from WPF host:

I suggest you start by testing these samples.

If it does not help then share some test case that I can run and see the problem happening. A simple hello-world application would be ideal.

[sofu456]

i was pluzz about loadcode method to create object in the code will cause this problem in the sample of cs-script. and codedom will crash if i try to call it.

[damian-666]

sounds like its a partial class issue from "The component does not have a resource identified by the URI "and so whatever Mainwindow.xaml + the Cs sode would be needed... the URI probably meanst some thing in the XAML of main window.... not sure if all evaluators parse xaml or if you really should bother to try . I don't thnk this is great design pattern for script, to show UI in directly script, that needs xaml + the window.cs to define the class, in the script , especiall if in netcore 6 -Windows and WPF .. And ths Show s Modal dialog that bocks the U thread or waits there for a OK or Cancl, and since its compilite into a temp assemply or something , the code might in in another "UIthread Context" n wpf.core. so much potential for problems.

do i would try just antother way to acheive what you want to do... use the logger, output some message to that,, then show the message outside of the script, or something....using the WPF dialog or text box directly in your host... theoretically should work in COMdom but i never got that workng and rosyln is much faster so i would rather deal wth the limitations of that..

also i see you called RosylinEvaluator.LoadCode ..

I put buttons to switch bettwen code dom and rosyln, turn of and on option and remember wahts best about Evaluator, is that its an abtracted into an common API.. you dont need to say RosylinEvaluator.LoadCode

just CSScript.Evaluator.LoadCode or whatever method, and first set

CSScriptLib.CSScript.EvaluatorConfig.Engine = IsEvaluatorSettingDOM? EvaluatorEngine.CodeDom : EvaluatorEngine.Roslyn;

I do change IsEvaluatorSettingDOM to true or false via a button on my host, to experiment.. at runtime.. that is one of the big advantanges of CSScript architecture that others dont let you do. YOu can change it at runtme as needed or even if one fails try the other one..

[Aytackydln]

Where are wpf samples? I also started getting this error when I switched from .net 4.7 to .net 6. Both CS-Script 4 and CS-Script.Core 2 gives me this error.

Also, recently started to publish my software self-contained. So I have only Roslyn evaluator.

Edit: I'm using scripting for user-created scripts like devices and rgb effect layers, not creating UI controls

[Aytackydln]

I don't know if creating a hello-world will recreate the issue but I will share my case:

Check out dev branch: https://github.com/Aurora-RGB/Aurora/tree/dev

Unzip the script to %appdata%\Aurora\Scripts\Devices rpi_script.zip

Then just run the application. Application is about controlling rgb devices. Shouldn't change anything in the system

[oleg-shilo]

The sample is in the codebase as in the post

I have created the branch for you that shows your script being loaded in WPF hos successfully. It is in the very same code sample: https://github.com/oleg-shilo/cs-script/tree/Issue_316/src/CSScriptLib/src/Client.WPF

[Aytackydln]

I've successfully reproduced the issue. It seems this error happens creating new control AFTER using evaluator.

I created and showed a new display by user input and I get this error in the demo application https://github.com/Aytackydln/cs-script/blob/Issue_316/src/CSScriptLib/src/Client.WPF/MainWindow.xaml.cs#L65

changed to .net 6 just because I don't have .net 7 on my pc

[oleg-shilo]

It is really a strange one. Somehow WPF runtime fails to load the window if CodeDom was used for loading the script. Seems like a hard-to-explain case. Not sure how loading an assembly can interfere with WPF.

Anyway, you can solve your case by simply deleting the CodeDom use-case:

Test_Issue_316();
// Test_CodeDom();
// Test_Roslyn();

[Aytackydln]

Aurora only uses default/roslyn evaluator and still crashes. I tried but couldn't reproduce in sample project

[sofu456]

thank you, @oleg-shilo . i have solve this problem by the dotnet script of microsoft.codeanalysis.csharp.scripting

[Aytackydln]

@sofu456 can you also tell me exactly what did you do? Did you change the library versions?

[sofu456]

@Aytackydln yes,i use the microsoft library to solve it. you can search dotnet script in nuget and find the microsoft.codeanalysis.csharp.scripting library.

the code like this

var script1 = CSharpScript.RunAsync(code1).Result; var result1 = script1.ContinueWithAsync("new ScriptedClass().HelloWorld").Result; Console.WriteLine(result1.ReturnValue);

[oleg-shilo]

I also found the cause of the problem after calling Test_CodeDom. I got the hint from some older WPF forums discussing this problem when dynamically loading WPF assemblies. This is what scripting does too.

Similarly to that older problem, in our case, it was caused by the referenced assemblies being loaded in the AppDomain twice because they were loaded with Assembly.LoadFile, which does have this side effect. Changing it to Assembly.LoadFrom solves the problem. It fixes CodeDom evaluator. The fix will be available in the very next release.

As for microsoft.codeanalysis.csharp.scripting, it is that "Roslyn engine". :) CSScript.CodeDomEvaluator is a wrapper around csc.dll CSScript.RoslynEvaluator is a wrapper around microsoft.codeanalysis.csharp.scripting.dll

[Aytackydln]

Nice, glad it was solved. Can you tag me here when you release the next version?

[oleg-shilo]

Just released the version: https://github.com/oleg-shilo/cs-script/releases/tag/v4.6.2.0

[Aytackydln]

I tried 4.6.2 but I still get the same error

[oleg-shilo]

Sorry, I have checked and the branch Issue_316 works as expected. Meaning that most likely the fix has been lost during the branch merge.

I will investigate, but can you please check that the branch Issue_316 works for you? I have just updated the sample to completely match your test case.

[oleg-shilo]

I think I have found the problem. A silly one :) The package was not published yet. Nuget.org had only v4.5.0 at the time of your test. So you could not get v4.6.2 with the fix. Now the package is listed and available. Client.WPF.zip

The working sample is attached

[Aytackydln]

I had tried with .nupgk dll before, also tried with online nuget package and it still has the same error. I don't know what else can I do to reproduce the error.

[oleg-shilo]

Did you try the sample I attached? This would be a good test to see if the difference in our environments contributes to the error.

Anyway, the fix was to allow CodeDOM compiler (csc.exe) to be used in the hosted WPF scenarios. But since you have confirmed that you are going to use Roslyn and it works for you, then probably you are not blocked by all this. Am I right?

[Aytackydln]

I can't use CodeDOM because my application is self-contained. I am getting the error while using Roslyn compiler

[oleg-shilo]

There is some confusion here. Let's recapture.

This original issue (#316) was about WPF runtime failing to load in self-contained executable scenarios. It is an assembly-probing problem that is a defect in WPF runtime. I base my statement on the fact that WPF should resolve all resources regardless of how many external dependency assemblies are loaded in the current AppDomain. This also does not depend on the origin of the dependency assemblies: you can download them from nuget.org, compile them with VS, with raw-Roslyn or with cs-script Roslyn. Since it is WPF defect our chances of truly fixing the problem are close to none.

Though we can try to change the runtime environment to minimize the chances of problems occurring.

With your help, I was able to reproduce the problem for a framework-dependant build. I managed to find that the trigger for it was the use of Assembly.LoadFile for loading the external assembly. While it is a completely legitimate use this API LoadFile sometimes does have assembly loading implications in CLR assembly probing. That was my speculation and I decided to test it by switching to an alternative assembly loading API Assembly/LoadFrom. And indeed it suppressed the problem. And this is the change (817157b) that I shared with you. And the sample app 3 posts above.

Thus what I shared with you is the sample that works as expected but only if it is built as no-self-contained app. If it does not help and I can still give it a try but I will need your help with converting that sample in the self-contained app. For some reason when I build it with dotnet publish --self-contained -r win-x64 I cannot even start the app.