After struggling with many changes and problems due to a recent CefSharp WinForms upgrade to 91.1.211 from V79.1.360, I thought I was all fixed up with THIS post. :-) However, while at the moment my application is now working, I have developed the following warnings subsequent to adding the <CefSharpBuildAction>Content</CefSharpBuildAction> line to the proj file:
warning MSB3178:
..\packages\CefSharp.Common.91.1.211\buildTransitive..\CefSharp\x86\CefSharp.BrowserSubprocess.Core.dll' is incorrectly specified as a file.
..\packages\CefSharp.Common.91.1.211\buildTransitive..\CefSharp\x86\CefSharp.BrowserSubprocess.exe' is incorrectly specified as a file.
warning MSB3187:
..\packages\CefSharp.Common.91.1.211\buildTransitive..\CefSharp\x86\CefSharp.Core.Runtime.dll' targets a different processor than the application.
I have excluded only 3 .pdb files for publishing, eliminating 3 minor warnings referencing security. All target CPU references are set to AnyCPU and Prefer 32-bit is checked, as I believe has been recommended.
Is there anything that can be done to eliminate any of these warnings and clean this up once and for all?
Thanks in advance.
Related
I am trying to convert a Windows Forms application to UWP using the Desktop Bridge. Since I have (most of) the source code, I'm attempting the conversion using Visual Studio, as opposed to the command-line tool. My application uses some third-party DLLs whose source code I don't have.
After adding a new JavaScript UWP project to my solution, I'm placing the original application's DLLs in a project subfolder as explained in the documentation.
Some of these DLLs are causing strange errors when I build the UWP project. The errors seem to be caused by duplicate resource entries in the DLLs, but curiously enough, these DLLs are referenced without issue in my standard Windows Forms project.
The errors state:
Duplicate entry
'DevExpress.Data.PropertyNamesRes/DevExpress/XtraPrinting/XpsDocumentOptions'
or one of its parents is defined as both resource and scope, which is
not allowed
I've been digging and searching about these errors for hours but I haven't found any meaningful information. I also used ILDASM to analyze the DLL headers but found no obvious issues in them. Has anyone here faced similar issues? Thanks in advance for any information.
Without seeing the complete error is difficult to say, but I've seen similar errors processing resources. If this is the case, this could be the same as this issue
And can be solved adding this property to the jsproj:
<AppxGeneratePrisForPortableLibrariesEnabled>false</AppxGeneratePrisForPortableLibrariesEnabled>
I'm just about to upgrade to v0.88.1 of Realm dotnet. I noticed that it has started using the .NET standard packages.
I also noticed that one of the packages is System.Diagnostics.Debug.4.0.11
Is this intentional. Will it be ignored in a release build? IS there anything I should be concerned about here?
Thanks in advance
TL;DR: nothing to worry about.
The assemblies brought in are just reference assemblies (already part of mscorlib) and will not be duplicated in the final application bundle. If you have enabled linking, unused parts of mscorlib (such as System.Diagnostics.Debug) will be linked away during build. Otherwise, they will be included, but will be ignored, as nothing is using them.
As a side note, those packages are included due to the dependency on Remotion.Linq.
For now i'm working on complicated Qt project and trying to eliminate many of warnings which appears when i'm trying to build project with using of different compilers (gcc,clang,msvc). Full rebuild of project takes up a long time.
Is there a some tool or maybe a artful approach to rebuild only modules that has warnings on previous build?
I think it might be reached by deleting (or outdating) those modules. Thus Make utility can rebuild them for me.
As the earlier comment say, only do a normal build. Anything that didn't compile last time will now compile. This of cause requires that you set a compiler flag to treat warnings as error or the compiler will create object files even though there are warnings. And the above strategy will fail.
i have to fight against a strange issue in my company. we have 2 .net 2.0 (old, i know) apps, which start with an .asmx-file. the code-behind calls a c#-file, which includes a include abcd directive, whereby abcd originates from a 3rd-party company.
one app is in test and it works fine. the identical one is in production and fails with the error Could not load file or assembly 'abcd.dll' or one of its dependencies. The specified module could not be found.
when i look in the related web.config-files, none of them includes a pointer to abcd.dll, which i first do not understand in the context of the productive environment, where everything works. secondly when i look inside the \bin-folder, i see the related assembly/dll. again: this is identical in both systems.
the only difference of both systems is the fact that visual studio 2.0 (does this really exist?) is available on the test system.
please note: i am aware that assemblies have to be added via solution explorer in visual studio too. but i cannot do this as such an installation is not allowed here. but again: in web.config on the test server no reference can be found in the related web.config and everythings works fine.
so my question is: how to get this thing working in productive env?
thanks in advance
You may want to run Dependency Walker (depends.exe) http://www.dependencywalker.com/ and point it at to detect if any dependencies are missing.
I'd also look in the GAC (C:\Windows\assembly) to see if there are any related differences there.
Also, compare IIS setting on the two machines.
We ran into an interesting issue that I've not experienced before. We have a large scale production ASP.NET 3.5 SP1 Web App Project in Visual Studio 2008 SP1 which gets compiled and deployed using a Website Deployment Project. Everything has worked fine for the last year, until after a check-in yesterday the app started critically failing with BadImageFormatException.
The check-in in question doesn't change anything particularly special and the errors are coming from areas of the app not even changed. Using Reflector we inspected the offending methods to find that there were garbage strings in the code (which .NET Reflector humorously interpreted as Chinese characters). We have consistently reproduced this on several machines so it does not appear to be hardware related.
Further inspection showed that those garbage strings did not exist in the Assemblies used as inputs to aspnet_merge.exe during deployment.
aspnet_merge.exe / Web Deployment Project Output
Assemblies Properties:
Merge all outputs to a single assembly
Merge each individual folder output to its own assembly
Merge all pages and control outputs to a single assembly
Create a separate assembly for each page and control output
In the web deployment project properties if we set the merge options to the first option ("Merge all outputs to a single assembly") we experience the issue, yet all of the other options work perfectly!
My question: does anyone know why this is happening? Is there a size-limit to aspnet_merge.exe's capabilities (the resulting merged DLL is around 19.3 MB)? Are there any other known issues with merging the output of WAPs?
I would love it if any Assembly format / aspnet_merge.exe gurus know about any such limitations like this. Seems to me like a 25MB Assembly, while big, isn't outrageous.
You might try running PEVerify on it and see what you get.
To me it sounds like an encoding issue ... but I'm not sure why that would happen. There technically is a limit to the amount of metadata that can fit into the metadata tables in an assembly, but I doubt if that is the problem.
You could see the size of the metadata tables if you open the exe in Ildasm, you could try looking at the statistics (View->Statistics) or the counts of the metadata tables which is a 2 step process: 1. View->Metainfo->Raw:Count,Sizes 2. Press Ctrl+M
Doesn't the BadImageFormatException get thrown when you attempt to run x64 code on x86?