I am trying to use a RCL library within a WinForms BlazorWebView. The problem is that the RCL library provides some static javascript files which i try to include in the BlazorWebView. So i added the scripts to the index.html i use, with the path pointing to "_content/{lib_name}/{path_to_file}"
e.g. <script src="_content/BlazorComponents/adaptivecards/adaptivecards-designer.js"></script>
The referenced files are included in the RCL library in the wwwroot folder.
BlazorComponents
-- wwwroot/
---- adaptivecards/
------ adaptivecards-designer.js
The problem i have is that somehow in the WinForms BlazorWebView these files are not there (i get the 404 in the browser control console).
If i use the same RCL project in a blazor server application it works perfectly fine. It even works in a WPF BlazorWebView application.
I uploaded the example for it here: https://github.com/toba-pl/winforms-blazor
The WPF example works completly fine while in the WinForms example the javascript files are missing.
What am i doing wrong here, how can i get static files from an RCL lib into the BlazorWebView in WinForms?
I already tried adding the static files directly to project containing the BlazorWebView, but then i get the following error: Conflicting assets with the same target path... and this anyways seems more like a workaround.
Also tried the same with the WPF BlazorWebView equivalent as mentioned above, you can also check it in the linked repo, there it works completly fine.
Related
I have found numerous articles on StackOverflow and elsewhere stating that if you wanted to output your files to the bin folder using ClickOnce, you should set the
BuildAction: Content
CopyToOuputDirectory : Copy if newer
but some of my binaries are located in a Dependencies subfolder located in the root of my project and when I publish the content, they are being outputted to
<wpf app folder>\dependencies instead of being in the <wpf app folder> causing my app to not function properly.
Any suggestions on how I can change this to force ClickOnce to output specific files to <wpf app folder>\ irrespective of where the Source files are located.
I eventually found a work-around which I don't like but I need to move on. To circumvent this problem I added the required libraries to the root of my project as links and still set the BuildAction to Content and CopyToOutputDirectory to Copy if newer.
I thought I'd explain it with an example as it may make a bit more sense.
Project Path: C:\Work\MyApp and it contains the following sub-folders:
D:\Work\MyApp\MyApp.csproj
D:\Work\MyApp\MyApp.xaml
...
D:\Work\MyApp\Bin\Debug
D:\Work\MyApp\Bin\Release
D:\Work\MyApp\Bin\Release\MyApp.exe
D:\Work\MyApp\Depedencies\LibA.dll
D:\Work\MyApp\Depedencies\LibB.dll
etc...
The libraries are third-party tools and are actually contained in their own folder:
D:\Tools\MyThirdPartyLib\Distributation\LibA.dll
D:\Tools\MyThirdPartyLib\Distributation\LibB.dll
By having the libraries in D:\Work\MyApp\Dependencies did not work as ClickOnce would install the app in:
C:\Users\\AppData\Local\Apps\2.0...\MyApp.exe
and it installed the files located in the Dependencies sub-folder in:
C:\Users\\AppData\Local\Apps\2.0...\Dependencies\LibA.dll
C:\Users\\AppData\Local\Apps\2.0...\Dependencies\LibB.dll
Which caused my app not to work.
To get around it, I ended up adding LibA.dll and LibB.dll to the root of my project as "Linked files" and set their BuildAction and CopyToOutputDirectory but not by pointing the linked files to
D:\Work\MyApp\Depedencies\LibA.dll
D:\Work\MyApp\Depedencies\LibB.dll
but instead pointing them:
D:\Tools\MyThirdPartyLib\Distributation\LibA.dll
D:\Tools\MyThirdPartyLib\Distributation\LibB.dll
And this seems to have done the trick. My only beef about it is that now I've got 10 odd files listed in the root of my project in visual studio which I don't like:
MyApp Solution
- MyApp Project
- MyApp.csproj
- MyApp.xaml
- ...
- LibA.dll
- LibB.dll
- ...
But it will have to do for now.
Hope it helps others!
I have been programming on a winforms project for about a month days. Recently one of the form designers always show an error page.
When the project is just loaded on VS, there's no error. After I do some modification then rebuild it will show the error page of:
The component 'LiveCharts.Wpf.DefaultLegend' does not have a resource identified by the URL '/LiveCharts.Wpf;component/defaultlegend.xaml'.
and the call stack shows:
at System.Windows.Application.LoadComponent(Object component, Uri resourceLocator)
at LiveCharts.Wpf.DefaultLegend.InitializeComponent() in c:\Users\btord\Documents\Projects\LiveCharts\WpfView\DefaultLegend.xaml:line 1
at LiveCharts.Wpf.Charts.Base.Chart..ctor() in c:\Users\btord\Documents\Projects\LiveCharts\WpfView\Charts\Base\Chart.cs:line 82
at LiveCharts.Wpf.CartesianChart..ctor() in c:\Users\btord\Documents\Projects\LiveCharts\WpfView\CartesianChart.cs:line 40
at LiveCharts.WinForms.CartesianChart..ctor() in c:\Users\btord\Documents\Projects\LiveCharts\WinFormsView\CartesianChart.cs:line 46
at Controls.Chart.MyChart.InitializeComponent()
at Controls.Chart.MyChart..ctor()
I checked the path but found no 'c:\Users\btord' directory and a few days ago I moved my Documents directory to D driver.
Sometimes after I build on release it will show another error page of:
Could not load file or assembly 'LiveCharts.WinForms, Version=0.9.6.0, Culture=neutral, PublicKeyToken=0bc1f845d1ebb8df' or one of its dependencies.
And there's no error in source code of the designer at all, neither when building. The execute file can run healthily.
It seems to commonly happen when multiple copies of live charts dll's are present in a solution build.
For me it was used both in the main executable and a plugin class library building in a sub folder. The effect is two copies of the Live Charts dll's in different folders which it doesn't like.
Packages.config
If using a packages.config file to handle references you can set the LiveCharts references to "CopyLocal"=false for the extra projects. This stops multiple copies of the dll's being included the build. It will happily use the copy loaded in the main project.
Package References
Sadly there isn't an option to not copy the files when using the newer style package references.
Removing extra copies post build seems the easiest workaround I've found.
In Project Properties, Build events page, post build event command line box add
del $(TargetDir)LiveCharts.*
$(TargetDir) is your projects output path.
I checked a lot of MEF questions here but I can't imagine what my problem is. Here's what's happening:
I have a desktop WPF app that I'm deploying with AdvancedInstaller. I use .NET 4.0 and MEF to compose parts. Some parts are in the main project, so they are inside the app.exe file. Other parts are inside class libraries that reference the main project, so they are inside somename.dll files.
The problem:
While running the app from VS, both in Debug and in Release, everything is fine. Once I deploy the app, some of the dlls say that they have no parts (zero) to export.
I checked the following:
all dlls are available in the deployment and the catalog is finding the files
the export types and names are correct, after all, everything is working while in Visual Studio
when I try to add the parts from the dlls, I get that the number of parts is zero ONLY IN DEPLOYMENT.
This is the code that's not findind parts in the deployed app:
var catalog = new AggregateCatalog();
string path = Environment.CurrentDirectory.ToString();
DirectoryCatalog qualitycontrol = new DirectoryCatalog(".", "QualityControl.exe"); //this is my main assembly
DirectoryCatalog qualitymix;
catalog.Catalogs.Add(qualitycontrol); //this finds the parts and always works fine
if (File.Exists(path + #"\QualityMix.dll"))
{
qualitymix = new DirectoryCatalog(".", "QualityMix.dll"); //the file exists in the deployment
catalog.Catalogs.Add(qualitymix); //the "qualitymix" catalog shows more than 20 parts if run with VS, but 0 parts in deployment
}
The only thing that works (but it's very slow to start the app) is the following:
var catalog = new DirectoryCatalog(".", "*");
This has the problem that it needs to check more than 100 files present in the working directory, and I cannot deploy my plugin dlls in a different dir.
Why is it that a DirectoryCatalog looking at all files finds the parts, but a DirectoryCatalog looking at a single part does not? How can I debug this issue if it only happens in the deployed app?
---Edit: this problem is only happening with certain dlls, the files are found and for other dlls the parts are also found. I'm using the same Export/Import procedure in all dlls, but somehow some of them show no parts in deployment
Anything you can suggest will be helpfull, thank you guys!
NEW INFO!
I tried loading my dll with an AssemblyCatalog. It works in Visual Studio (Debug and Release) but when deployed I get the following errors:
1st try:
if (File.Exists(path + #"\QualityMix.dll"))
{
qualitymix = new AssemblyCatalog(Assembly.LoadFile(path + #"\QualityMix.dll")); //file is loaded and parts found in VS
catalog.Catalogs.Add(qualitymix);
}
Error: The module was expected to contain an assembly manifest. (Exception from HRESULT: 0x80131018).
Second try:
if (File.Exists(path + #"\QualityMix.dll"))
{
var name = AssemblyName.GetAssemblyName(path + #"\QualityMix.dll");
qualitymix = new AssemblyCatalog(Assembly.Load(name));
catalog.Catalogs.Add(qualitymix);
}
Error: Could not load file or assembly 'QualityMix.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I've looked for questions about these errors but nothing has been helpful so far. All projects are built for All CPUs, and the references look ok (this dll uses the same references as other projects that are loading ok).
Edit 2:
I tried the suggestion by #SuryaBhaskar to use LoadFrom instead of Load
if (File.Exists(path + #"\QualityMix.dll"))
{
qualitymix = new AssemblyCatalog(Assembly.LoadFrom(path + #"\QualityMix.dll"));
catalog.Catalogs.Add(qualitymix);
}
But I get the same error: Could not load file or assembly 'QualityMix.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
I managed to solve this issue by moving the code of the problematic dll to a new project. This solved the issue, somehow... though the reason remains a mistery to me.
Use LoadFrom instead of LoadFile or Load.If you use Load it will have conflicts with other assemblies on current AppDomain
Environment: WPF, .NET 4.0, VS 2010
I am developing an application which has one main app that will internally invoke sub application and the solution structure (mentioned only the required projects for simplicity) is as below:
Solution.sln
MainApp (WPF application)
SubApp (wpf application)
Assets (class library)
I have added reference to the Assets project into MainApp and SubApp. I added Setup project and:
Added MainApp primary output (this detects Assets.dll as a dependency).
Created a folder SubApp (right click Application Folder and add new folder) and added SubApp primary output inside this folder). This too detects Assets.dll as dependency (which is correct!)
When I build the setup project, run the MSI and install the application, I see target application folder (c:\program files\default company) structure as below:
MainApp
- MainApp.exe
- Assets.dll
- SubApp (folder)
- SubApp.exe
- Assets.dll (I don't want this to appear here simply because there will be SubApp1, SubApp2 and so on in future who all will refer to the same assets dll)
How can this be achieved? I am sorry if question has become too long but I believe in explaining things in one shot than to provide information in bits and pieces.
Why is it that when my Silverlight project is built, the output directory contains a bunch of culture specific directories:
ar\System.Windows.Controls.resources.dll
bg\System.Windows.Controls.resources.dll
ca\System.Windows.Controls.resources.dll
etc etc etc
Also the root of the build output contains:
System.Xml.Linq.dll
System.windows.Controls.dll
I have gone through the projects in my solution and made sure that "Copy Local" is set to false for all the referances of the mentioned dll files.
Those 2 files were set to true, but I did switch them to false. Despite my effort to google an answer, I remain stuck.
You have dependent libraries or DLLs or references that expect these SDK assemblies.
Those directories contain the language-specific resource files and will be there if the System.Windows.Controls assembly is included in any way in any part of your project or its dependencies.
Double check that ALL REFERENCED ASSEMBLIES are set to copy local false.