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.
Related
For a long time, I have been very successful at non-invasively customizing many .NET Framework builds by setting CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets as environment variables in a command-line shell that corresponds to a given development/build workspace.
I would set these environment variables to point to custom msbuild targets files that would then be automatically imported (before and after respectively) the import of the standard Microsoft provided targets files. This has worked great for a long time, but now .NET Core comes along and I find no mechanism quite like that.
I am aware of Directory.Build.props and that does not appear to be equivalent. For one, it is invasive requiring me to add a file to a source tree that I don't want to necessarily touch in order to customize its build (maybe its an open source project and I don't want to be injecting new files into it). For two, it doesn't provide the dual Before/After import hooks which are very important (if this duality weren't important Microsoft would never have provided it).
I also don't like dropping magic files in magic global locations as my build policies/customizations are themselves versioned source code which can vary from one developer workspace to another (even on the very same machine for the very same developer).
It seems odd that Microsoft would fail to retain such a long-standing and fundamentally useful msbuild customization capability in .NET Core. Am I missing an equivalently powerful, easy to use and non-invasive mechanism? Is it there and I just haven't found it?
CustomBeforeMicrosoftCommonTargets and CustomAfterMicrosoftCommonTargets are still part of MSBuild 15 which is included in VS 2017 and the .NET Core SDK.
Setting them as global variables will still import them and override the default locations used if not set. Use the /bl argument to generate a binary build log and the MSBuild structured log viewer to diagnose issues you may have with it.
I have .NET Core solution with ~30 projects, and I don't get one thing - each project compiled Bin output is very huge. Basically it contains whole bunch of Microsoft.AspNetcore.* and System.* assemblies, which makes output about 15-30mb (even for really small projects).
The solution divided into smaller projects with purpose to make it less coupled, but now it makes more troubles than it helps - overall size of all compiled projects is around 700mb..
I agree that it would be OK for "startup"/"composite root" projects, where everything should be in one place, but now it looks like every project is "published", or like compiled as "standalone" and not using installed frameworks.
It's not a problem as such, but it makes the solution not so robust in terms of CI/CD, publishing artifacts, etc. Any ideas what might be wrong? Is it really as designed?
One possible reason is that for some historical reason my solution targets net461 (aka "full" .NET Framework). However I'm considering porting everything to netcoreapp1.x/netstandard. I tried to do it with some projects - and it looked like for "library" projects it copies only few assemblies, but for some other projects (e.g. tests written with xUnit) - there are still a lot of "framework-based" DLLs, that could be used from global cache or smth.. Even in net461 current situation is still a bit weird.
I also was trying to put all built artifacts into one folder on CI server, but there are other issues with it - like third-party libraries conflicts, when different version libraries in different projects are used. It's understandable for third-party libraries, but "framework" libraries could be "smarter"..
Just for reference, full list of assemblies being copied to Bin output:
Autofac.dll
Autofac.Extensions.DependencyInjection.dll
AutoMapper.dll
FluentAssertions.Core.dll
FluentAssertions.dll
JetBrains.Annotations.dll
Microsoft.AspNetCore.Antiforgery.dll
Microsoft.AspNetCore.Authorization.dll
Microsoft.AspNetCore.Cors.dll
Microsoft.AspNetCore.Cryptography.Internal.dll
Microsoft.AspNetCore.DataProtection.Abstractions.dll
Microsoft.AspNetCore.DataProtection.dll
Microsoft.AspNetCore.Diagnostics.Abstractions.dll
Microsoft.AspNetCore.Diagnostics.dll
Microsoft.AspNetCore.Hosting.Abstractions.dll
Microsoft.AspNetCore.Hosting.dll
Microsoft.AspNetCore.Hosting.Server.Abstractions.dll
Microsoft.AspNetCore.Html.Abstractions.dll
Microsoft.AspNetCore.Http.Abstractions.dll
Microsoft.AspNetCore.Http.dll
Microsoft.AspNetCore.Http.Extensions.dll
Microsoft.AspNetCore.Http.Features.dll
Microsoft.AspNetCore.HttpOverrides.dll
Microsoft.AspNetCore.JsonPatch.dll
Microsoft.AspNetCore.Localization.dll
Microsoft.AspNetCore.Mvc.Abstractions.dll
Microsoft.AspNetCore.Mvc.ApiExplorer.dll
Microsoft.AspNetCore.Mvc.Core.dll
Microsoft.AspNetCore.Mvc.Cors.dll
Microsoft.AspNetCore.Mvc.DataAnnotations.dll
Microsoft.AspNetCore.Mvc.dll
Microsoft.AspNetCore.Mvc.Formatters.Json.dll
Microsoft.AspNetCore.Mvc.Localization.dll
Microsoft.AspNetCore.Mvc.Razor.dll
Microsoft.AspNetCore.Mvc.Razor.Host.dll
Microsoft.AspNetCore.Mvc.TagHelpers.dll
Microsoft.AspNetCore.Mvc.Versioning.dll
Microsoft.AspNetCore.Mvc.ViewFeatures.dll
Microsoft.AspNetCore.Razor.dll
Microsoft.AspNetCore.Razor.Runtime.dll
Microsoft.AspNetCore.ResponseCaching.Abstractions.dll
Microsoft.AspNetCore.Routing.Abstractions.dll
Microsoft.AspNetCore.Routing.dll
Microsoft.AspNetCore.Server.IISIntegration.dll
Microsoft.AspNetCore.Server.Kestrel.dll
Microsoft.AspNetCore.WebUtilities.dll
Microsoft.CodeAnalysis.CSharp.dll
Microsoft.CodeAnalysis.dll
Microsoft.DotNet.PlatformAbstractions.dll
Microsoft.Extensions.Caching.Abstractions.dll
Microsoft.Extensions.Caching.Memory.dll
Microsoft.Extensions.Configuration.Abstractions.dll
Microsoft.Extensions.Configuration.Binder.dll
Microsoft.Extensions.Configuration.dll
Microsoft.Extensions.Configuration.EnvironmentVariables.dll
Microsoft.Extensions.Configuration.FileExtensions.dll
Microsoft.Extensions.Configuration.Json.dll
Microsoft.Extensions.DependencyInjection.Abstractions.dll
Microsoft.Extensions.DependencyInjection.dll
Microsoft.Extensions.DependencyModel.dll
Microsoft.Extensions.FileProviders.Abstractions.dll
Microsoft.Extensions.FileProviders.Composite.dll
Microsoft.Extensions.FileProviders.Physical.dll
Microsoft.Extensions.FileSystemGlobbing.dll
Microsoft.Extensions.Globalization.CultureInfoCache.dll
Microsoft.Extensions.Localization.Abstractions.dll
Microsoft.Extensions.Localization.dll
Microsoft.Extensions.Logging.Abstractions.dll
Microsoft.Extensions.Logging.Console.dll
Microsoft.Extensions.Logging.dll
Microsoft.Extensions.ObjectPool.dll
Microsoft.Extensions.Options.ConfigurationExtensions.dll
Microsoft.Extensions.Options.dll
Microsoft.Extensions.PlatformAbstractions.dll
Microsoft.Extensions.Primitives.dll
Microsoft.Extensions.WebEncoders.dll
Microsoft.Net.Http.Headers.dll
Microsoft.Win32.Primitives.dll
Newtonsoft.Json.dll
NLog.dll
NLog.Extensions.Logging.dll
NLog.Web.AspNetCore.dll
System.AppContext.dll
System.Buffers.dll
System.Collections.Immutable.dll
System.ComponentModel.Annotations.dll
System.ComponentModel.Primitives.dll
System.ComponentModel.TypeConverter.dll
System.Console.dll
System.Diagnostics.DiagnosticSource.dll
System.Diagnostics.FileVersionInfo.dll
System.Diagnostics.StackTrace.dll
System.Globalization.Calendars.dll
System.IO.Compression.dll
System.IO.FileSystem.dll
System.IO.FileSystem.Primitives.dll
System.Net.Http.dll
System.Net.Sockets.dll
System.Numerics.Vectors.dll
System.Reflection.Metadata.dll
System.Runtime.CompilerServices.Unsafe.dll
System.Runtime.InteropServices.RuntimeInformation.dll
System.Security.Cryptography.Algorithms.dll
System.Security.Cryptography.Encoding.dll
System.Security.Cryptography.Primitives.dll
System.Security.Cryptography.X509Certificates.dll
System.Text.Encoding.CodePages.dll
System.Text.Encodings.Web.dll
System.Threading.Tasks.Extensions.dll
System.Threading.Thread.dll
System.ValueTuple.dll
System.Xml.ReaderWriter.dll
System.Xml.XmlDocument.dll
System.Xml.XPath.dll
System.Xml.XPath.XDocument.dll
It seems I found it myself.. There are CopyLocalLockFileAssemblies and CopyNuGetImplementations flags for .NET Core projects (i.e. new-style *.csproj files).
For .NET Core it's:
<!-- dependencies coming from the package manager lock file should not be copied locally for .NET Core and .NETStandard projects -->
<CopyLocalLockFileAssemblies Condition="'$(CopyLocalLockFileAssemblies)' == ''">false</CopyLocalLockFileAssemblies>
For .NET Framework it's set as "true" by some reason. Therefore binaries are so big in size.
Regarding xUnit projects - they are also overriding these flags and set them to true. Actually tests are working with having them "false" when you are using dotnet xunit or dotnet test, but it should be really "true" if you want to use xUnit console runner.
It doesn't really help me, but at least it explains why it happens..
It's really frustrating to have project just with one class, which is ~5kb, but Binary output is 16Mb.
I had a similiar problem with a little .NET core console app targeting net461 (which brought me here).
The Microsoft.Packaging.Tools.Trimming tool (now found here) sort of did the job for me at the end, as most of the copied assemblies weren't used by my application anyway. Just install the nuget package and insert following lines in the project file:
<PropertyGroup>
<TrimUnusedDependencies>true</TrimUnusedDependencies>
</PropertyGroup>
This will check for unused dependencies and remove them. Maybe that can reduce the number of DLL files a little.
I'm hoping I just missed something in the README somewhere, but...
I have a library of VB.net code that I'm trying to package into a PCL, ultimately for use under Xamarin. The code is relatively straightforward, there's a lot of File I/O using streams and some SQL client code, and a smaller amount of UI and control related code.
So I made a new PCL project, but I was confused what to select, so I chose Windows Store and .Net 4.5. I then Add...ed the source files from an existing project. Now I'm getting errors on the most basic things - ArrayList does not appear to exist in spite of importing System.Collections, and StackTrace doesn't exist in Diagnostics. Even simple things like StringFormat and SortedDictionary aren't there.
Did I skip a step somewhere? Perhaps I didn't download the right libs from MS? Or maybe I have to manually include a Reference to something? Any ideas?
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 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