ExcelRichTextHtmlUtility does not appear in the EPPlus 4.5.1 library (or 4.1 for that matter). I see it's in the code in source control but doesn't get shipped I guess. Is there a particular reason or maybe I'm doing something wrong.
It's in the source code but not compiled as part of the project anymore. When I include ExcelRichTextHtmlUtility.cs, the following line does not compile:
s = System.Web.HttpUtility.HtmlDecode(s);
In taking a look at the project settings, EPPlus targets the .NET 3.5 Client Profile framework. The Client Profile is a subset of the framework which for example does not include System.Web, so HttpUtility cannot be used so they must have just simply excluded the class.
I couldn't find any reference to exactly when and why this was changed so this probably does not completely answer your question.
Related
We used FXCOP code analysis ("legacy") a lot in our solution. We are turning on many Microsoft rules, and also have written a large set of our own FXCOP-style analyzers for aspects of code that we wanted to have checked. And it all worked quite well in the "old" style Visual Studio C# projects, aimed at various .NET Framework versions (currently 4.7.2).
When, however, the same project is ported to the new "SDK-style" format, and made to target .NET Framework 4.7.2 by having net472, and we enable the code analysis by adding true, we run into a problem. Our custom FXCOP rules appear to still work well and output their warnings, but in the Error List window, there are no file names under the "File" column, and there is always line 1 under the "Line" column. Consequently, we can see the warning messages, but it is impossible to double-click on the warning and figure out the location in the source code the warning related to - which makes the whole code analysis useless. When I switch to the Output/Build window, I can also see the warnings there line by line, but the file name/line number information is missing here as well.
I am aware of the followings facts:
That Microsoft has ported many or all their FXCOP rules to Roslyn (".NET Analyzers") and they can/should now be used. However I need to use our own rules, not just the Microsoft rules. Rewriting our rules to Roslyn may be the right solution in the long run, but it would be a huge undertaking in short- or mid-term.
That FXCOP (legacy) analysis is not supported in .NET Core and .NET Standard projects in VS (as per https://learn.microsoft.com/en-us/visualstudio/code-quality/static-code-analysis-for-managed-code-overview?view=vs-2022 ). My project is not, however, for .NET Core or .NET Standard, as I described above. It is for .NET Framework 4.7.2 - the problem seems to be in the fact that it is the SDK-style. And the reason I need it in this format is because it is the format that I will then use to port to .NET Core/.NET 6+.
I have a found a partial solution to the problem. The reason FxCopCmd (which is used by this) does not emit file names and line numbers is because by default, in SDK-style projects, the PDB file format is set to portable. FxCopCmd does not understand the portable PDB. The solution is in Visual Studio project properties, set the "Debug symbols" to "PDB file, current platform". The corresponding setting in the .csproj file is
<DebugType>full</DebugType>
After making this change, the file names and lines numbers appear in the text output, and in their columns in Error List, and it is possible to click on warnings in the output or Error List, and you will be taken to the right place in the source.
What does not work yet: The "Suppress..." contextual menu commands in the Error List still do not appear.
I have a project with a custom control overriding a default control from the system.windows.forms namespace. This works fine, but I discovered I needed to modify a DLL this project depends on with some code that needs to know about the existence of this custom class; this code uses the class name of the control to do various things.
As the project depends on the DLL, and circular dependencies are not-a-good-idea, I moved the custom class to a third DLL which is a new project by cut-and-paste, and set the project and library to depend on this new lib, and set this new library to be built first, before the two other projects, and added an assembly reference.
So far so good; I can now import this new namespace and use it in my code. But, now the existing uses of the custom control are broken in any 'designer' based code, as they still point to the default namespace. I've tried adding a reference under Project Properties > Imported namespaces, yet this is insufficient: the code likely needs to contain the explicit line imports <myNamespace>. And while this is no-problem for regular files, when you have a designer file it's important to not manually modify it.
What's the easiest proper way of informing visual studio that any custom control named say X should now be accessed as myNamespace.X?
The procedure as done in the question is correct, with one caveat: Check the .NET version, and if different set the target version to the lowest common denominator. If you use a newer Visual Studio than the original that was used to make the solution, it's likely there's a newer .NET out as well. By default, the latest .NET will be used for new projects. Visual studio will also happily attempt to build the projects with disparate .NET versions, and complain that it can't find references, then surreptitiously hide the version mismatch as a "Warning", even though linking assemblies with different targets is by default impossible.
The designer will then happily accept the custom class even if it's defined in another project.
I need to send mail from a Windows Embedded Compact 7 device and I'm trying to use OpenNETCF.Net.Mail.
My project is in VB.NET, CF3.5 and when I add OpenNETCF.Net.Mail to the project references the building fails (without adding a single line of code related to that library).
I have added also OpenNETCF, OpenNETCF.Net and OpenNETCF.Windows.Forms without any problem.
I get no error in the output log, just at the end the word FAILED...
I have never used OpenNETCF before so I apologize if my error is trivial but I couldn't find any solution.
To get this problem it is enough to create a new SmartDevice project (VB.NET, CF3.5) and in the property of the project to add a reference to OpenNETCF.Net.Mail.dll: the project doesn't compile any more.
I just get a warning about a version conflict:
Consider app.config remapping of assembly "System, Culture=neutral, PublicKeyToken=969db8053d3322ac, Retargetable=Yes" from Version "2.0.0.0" [] to Version "3.5.0.0" [C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE\System.dll] to solve conflict and get rid of warning.
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3247: Found conflicts between different versions of the same dependent assembly.
Searching info about that warning I found that it is "safe" to ignore it because the OpenNETCF version that I'm using (2.3.12004.0) is compatible with CF3.5.
If I remove the reference to OpenNETCF.Net.Mail.dll and I add a reference to OpenNETCF.Windows.Forms.dll I get 5 warnings about remapping but the project compiles.
Anyone has a suggestion to solve my problem?
Thanks in advance.
Steve
Hi,
it seems that this topic is not very interesting but I've found the solution and I want to share it.
I contacted OpenNETCF support and Chris Tacke answered very kindly.
The solution is to remove from project references System.Xml.Linq that for some reason sometimes generates this kind of problem in VB.NET CF 3.5 projects.
I am a .NET Developer. I have a good understanding of how references work in .NET i.e. if you want to use AssemblyA.ClassA.MethodA in AssemblyB.classB.MethodB then you add a reference in Assembly A to Assembly B.
I am looking at a VB6 app and I get an error when I open it i.e. Errors during load. Refer to frmMain.log. I open frmMain.log and it says: "2142: Class MSComDlg.CommonDialog of control CommonDialog1 was not a loaded control class.". I have used WinMerge to compare the source code in the faulty project to a previous version of the project (which does not have the problem). The only difference is that the faulty project contains the following line in the client.vdp file:
Reference=*\G{08DBEFD7-6A19-4DCE-A533-5BDBB93683C8}#1.2#0#..\..\..\..\..\Windows\SysWOW64\Comdlg32.oca#Microsoft Common Dialog Control 6.0 (SP3)
Removing this line seems to resolve the problem. Why does this resolve the problem?
I have used Winmerge to compare yesterdays revision of the project (which does not have the problem) to todays revision of the project (which does have the problem). The only difference is the reference in the original post in the VBP file.
I would assume that someone installed the development version of this control on a different machine and then set a reference to it. When you try to open the project on your machine the reference fails. Or the control was uninstalled. It seems that the project was not using the reference and that it can be safely removed as it will still compile without the reference.
However, I have seen vb6 actually remove non-licensed controls from the form in question in this situation. So it may be that you can now compile because the form is missing a component that was there previously. Have you checked that frmMain has not changed, both the .frm and .frx files?
I'm trying to write a IL Weaver with Mono.Cecil, and for it to remain debugable in VS2010, I need the PdbReaderProvider class, or some similar implementation of ISymbolProvider. I've downloaded the latest Mono dlls from http://mono.ximian.com/daily/, but in the zip there is no Mono.Cecil.Pdb.dll. I've downloaded the source code from https://github.com/jbevain/cecil/tree/master/Mono.Cecil but I can't seem to be able to get that particular project compile under .net 4.
Could somebody help me out and point to a compiled working .net dll of Mono.Cecil.Pdb, preferably with a working PdbReaderProvider inside?
Indeed, you need to get the source from Cecil's github repository. Then you just have to open Mono.Cecil.sln inside VS 2010, select the solution configuration net_4_0_Debug (or net_4_0_Release) and build the solution. The solution is self contained so you don't need anything else.
You'll get both Mono.Cecil.dll and Mono.Cecil.Pdb.dll inside bin/net_4_0_Debug (or bin/net_4_0_Release).
Alternatively, get the NuGet package which includes all Cecil assemblies. If you're on the MS stack, of course.