I have VB.NET code in Visual Studio 2008 using an obsolete method and would like to suppress the warning. Unfortunately, following the recommendation is not a good solution, because it requires using a different class, which works differently, in important ways.
I'm trying to suppress the warning using System.Diagnostics.CodeAnalysis.SuppressMessage, but I don't know what to write as the parameters for the attribute and can't find any relevant reference.
I should also say that, right-clicking on the error in the error list I don't have any 'Suppress Message' option.
If you're using Visual Studio you can do the following.
Right click on the project and select "unload"
Right click on the project and select "Edit SomeProjectName.vbproj"
You should see two XML element tags with the name "NoWarn". Add the number 40000 to the list of numbers already present (make sure to do this for every NoWarn tag in the file)
Save the file
Right click on the project and select reload (you'll have to close the .vbproj file)
This will get rid of the warning. The number 40000 is the VB.Net error number for the obselete warning. You can suppress any warning in this fashion.
Note: If the NoWarn tag is not present, add it to the main PropertyGroup element with the following values
<NoWarn>40000</NoWarn>
In VS.NET you can right click on and suppress code analysis warnings. This will add the attribute for you.
However, the "don't use obsolete APIs" warning is not coming from code analysis, and so the SurpressMessage attibute won't work. This is a compiler warning.
For VS.NET you'd need to switch off this warning with...
/nowarn:0618
... at the command line (or just adding "0618" into the Suppress Warnings field on the csproj properties). You should do the same with whatever the VB warning number is.
I was able to resolve this with JaredPar's answer in my VB Project, thanks!
I did had same warning for my C# test project that I got removed by adding 618 in suppress warning section of Build Tab in Project Properties.
Please remember the Error Codes for VB and C# are different.
If one want to correct the these warnings then one need to install and use ODP.NET for Microsoft OracleClient Developers
Microsoft is deprecating System.Data.OracleClient, also known as Microsoft OracleClient. Microsoft OracleClient provider developers can use this opportunity to reevaluate which data provider to use for current and upcoming projects. Oracle recommends to start building new Oracle .NET applications with Oracle Data Provider for .NET (ODP.NET) and migrate existing applications to ODP.NET.
http://www.oracle.com/technetwork/topics/dotnet/index-085703.html
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.
In Visual Studio 2015 it is possible to select which version of the C# language is being coded in, as shown here.
I'm looking for the same option for VB.NET - how can I restrict syntax, etc. to old VB.NET versions?
I want to do this so that I stop accidentally using VB 14 features in a project I'm sharing with someone using Visual Studio 2012. I'd rather not spam up my machine with a Visual Studio 2012 install or have to create a new VM for a fairly occasional requirement.
NOTE: I don't want to change the target .NET Framework version.
The VB.NET compiler has the /langversion option for this. Also supported by MSBuild. But not by the IDE, that makes it awkward to change it.
Still possible, you have to edit the .vbproj file. Use a text editor, Notepad will do. And copy/paste this snippet, insert it in the 4th line so it is effective for all configurations and platforms:
<PropertyGroup>
<LangVersion>12</LangVersion>
</PropertyGroup>
And double-check that it is effective:
Module Module1
Sub Main()
Dim test As String
Console.WriteLine(NameOf(test))
End Sub
End Module
Output:
error BC36716: Visual Basic 12.0 does not support 'nameof' expressions.
Well, that works, also flagged by IntelliSense with red squiggles. You probably want to create your own project templates so you don't have to do this over and over again. Use File > Export Template.
If you're using ReSharper it turns out this is an option:
Left Click on the project in Solution Explorer
Select the Properties Window (not the Project Properties - you want the properties snap in)
Under ReSharper options there is a "VB Language Level" option, which gives options all the way back to VB.NET 8.
I haven't tested how well this works.
I don't think this is possible when using VB.
See this related connect bug: Connect: VB 14 compiler removes line continuations even when web.config specifies VB 8 as compiler
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 created a new VB.net windows applications project and added a reference to my utilities project like I have done many times before. When I start coding, the editor will find the utility namespace without difficulty but when I build I get "Type My.Utils.Data is not defined".
I've compared my project to my other projects and can't find a difference.
When I try to debug, I get a dialog saying "Visual Studio cannot start debugging because the debug target "C:.....\myproject.exe" is missing
You need to make sure that the consuming project is targeting a .NET Framework version which is equal to or higher than the other project that it is referencing. If the referenced project is targeting a higher version of the framework, Visual Studio will not give you a useful message like, "Wrong Framework Version". Instead, it gives you a very confusing error about the assembly being missing, even though it's there.
I ran into this error and had a more unusual root cause. I'll add it here because someone may experience the same. (I don't expect this to be the "normal" cause of this error.) Anyway, I created a service reference and I removed the text "Reference" from the name of it and called it "ServiceName" rather than "ServiceNameReference. Apparently that created a naming conflict that blew up the reference.vb file.
I'm using LINQ to SQL as my data access layer for a new project. I have added my database tables to the designer and all is well.
Whenever I use one of these classes in a function, Visual Studio warns me that 'Type xxxx is not CLS-compliant' or that 'Return type of function xxxx is not CLS-compliant'
Is this a problem with the classes that LINQ to SQL generates? Does it matters? Can I disable these warnings anywhere? My VS error list is clogged up with these warnings making it hard to see anything else.
EDIT:
Sorry, I should have mentioned these are VB.NET projects. :)
I found this link on MSDN Connect:
When adding inheritance relations
between classes in the O/R designer,
the acess level on the generated
backing store member of the Id
attribute, "_Id", is changed from
private to protected, causing the CLS
rule violation. The Id property is
used in an association between the
classes.
If you want to get rid of the warnings, you can use:
#pragma warning disable 3021
Or, if you want to disable them project-wide, add 3021 to the "Suppress warnings" field in the Build tab of your project's properties in Visual Studio.
Ben M has the right idea on the problem.
The quickest way to solve this on a VB.Net project is to make the assembly not CLSCompliant and hence avoid those warnings. Adding the following line to any of your files will do the trick
<Assembly: CLSCompliant(False)>
Best file to add it into is AssemblyInfo.vb inside of the "My Project" folder.
It ultimately depends on what types are being returned by your database and what the names of those types are.
One issue regarding CLS compliance is a type that has two publicly exposed members which differ in name only by case, e.g. MyField and myField.
Here's an article that should help you determine where your CSS compliance issues are occuring and deal with the issues. If you need more help, pose some code and we'll see what we can do.
I usually see that error when I'm consuming types from one assembly which does not have the CLSCompliant attribute in another assembly which does.
That is, are your Linq to SQL classes in a different project than the functions you're writing? Have you specified [assembly: CLSCompliant(true)] in some but not all of the projects in your solution?