We Keep Coding

How to set Properties by Interface and not get compilerwarnings

I have a lot of classes that share a lot of properites and have a lot of common interfaces.
It happens very regularly that i want to construct an object with data from another object and they share an interface. To make that more easy i have this neat little method:
public static List<PropertyInfo> InterfaceProperties(Type type)
{
return new[] {type}
.Concat(type.GetInterfaces())
.SelectMany(i => i.GetProperties(BindingFlags.Instance | BindingFlags.Public)).ToList();
}
public static void SetFromSimilar<TInterface>(TInterface destination,TInterface source)
{
var properties = InterfaceProperties(typeof(TInterface));
foreach (var property in properties)
{
var val = property.GetValue(source, null);
property.SetValue(destination, val, null);
}
}
It works fantastic because now i can do this:
public class MyClass: IMyInterface
{
public MyClass(IMyInterface otherClass)
{
SetFromSimilar(this,otherClass)
}
....MyProperties.....
}
Now rider complains about non-nullable properties being uninitialized which makes sense. I know they are initialized but for the IDE thats hard to see and i get compilerwarnings. This throws me off because i see it marked as a potentialy error and i have to think everytime if there is something wrong.
Is there a substitute for my method where this will not happen?
Ok i got no answers so far. Is it not possible? Is this not a normal usecase? Is it somehow possible with net5?
The compiler warning:
C:\My\File\Path\MyClass.cs(10,16): warning CS8618: Non-Nullable-Eigenschaft "MyProperty" muss beim Beenden des Konstruktors einen Wert ungleich NULL enthalten.
Erwägen Sie eine Deklaration von "Eigenschaft" als Nullable. [C:\My\File\Path\MyProject.csproj]
It tells me to maybe make the property nullable which i absolutely don`t want.

The compiler and analyzers cannot usually (or easily) interpret reflection code, so it is quite reasonably unconvinced as to their assignment and nullability. If you know something is correct that the compiler can't verify: just add a suppression for the warning over that particular code block, via #pragma, a [SuppressMessage(...)] on the affected code, or a suppression file (which is just [assembly:SuppressMessage(...)] in a different file, with a Target to tell the compiler what it applies to). Rider may have some other ways of suppressing messages, via the context menu.
Note: if you go this route, you may also want to add assertions - especially in a DEBUG build - that what you belive to be true: is actually true.
If you're using C# 9, you could add a smattering of dammit (!) markers, or turn off nullability checking for that code.

Well yea, this does not look like a perfectly elegant solution to your problem, in my opinion. Here's some solutions I can think of, in order of elegance:
1. Quick & Brute force
Just tell rider to not complain about it with a #pragma statement, I believe in your case it should be this:
#pragma warning disable CS8618
[code that throws the warning]
#pragma warning restore CS8618
2. Write code to generate code
Write yourself a small application that extracts those common interfaces to autogenerate set-value code for each
3. Don't mix data with control code
If you need to set data on classes with different controllers, i.e. classes, put it into its own data class. Tadaaa, you just gained the ability of class inheritance for setting common values.

How to avoid warning CS0649 while using FileHelpers Module

I am using the FileHelpers nuget to read the files. It works as excepted but it throws me a warning when I tried to debug in Visual Studio.
How to get rid of warning CS0649: Field 'Orders.Freight' is never assigned to, and will always have its default value null ?
class Orders : INotifyRead
{
[FieldFixedLength(10)]
public string Freight;
public void BeforeRead(BeforeReadEventArgs e)
{
if (e.RecordLine.StartsWith("Machine"))
// ||
// e.RecordLine.StartsWith("-"))
e.SkipThisRecord = true;
}
public void AfterRead(AfterReadEventArgs e)
{
// we want to drop all records with no freight
if (Freight == "_raw")
e.SkipThisRecord = true;
}
}

No, do not explicitly assign a default value to Freight.
The warning is legitimate, because you never really assign a value to the field.
You do not assign a value, because the field gets populated by magic. (Incidentally, that's why I do not like magic; but that's a different story altogether.)
So, the best approach is to acknowledge the fact that the warning is legitimate but accounted for, and to explicitly suppress it.
So, take a look at the documentation of the #pragma warn directive:
https://msdn.microsoft.com/en-us/library/441722ys.aspx

For the sake of completeness, I'm just going to combine blins' answer and Mike's answer - nothing original, just trying to help the next person who runs across this page.
Per blins: You may set the value equal to null and the first warning "Field XYZ is assigned to but never used"
public string Freight = null; //or = "", or = default(string) (which is null)
Per Mike, the "magic" he's talking about is Reflection. The variable is assigned to at runtime. This is something the compiler doesn't detect. More on Mike's answer about suppressing the warning found here: Suppressing "is never used" and "is never assigned to" warnings in C#
To suppress warnings for "Field XYZ is never used", you do this:
#pragma warning disable 0169
... field declaration
#pragma warning restore 0169
To suppress warnings for "Field XYZ is never assigned to, and will always have its default value XX", you do this:
#pragma warning disable 0649
... field declaration
#pragma warning restore 0649

You essentially have two choices and which way to go really depends on the intent (to suggest one or the other is subjective). First, you could eliminate the warning if the design requirement of your Orders type dictates that it should have a null default value.
public string Freight = null;
The above merely clarifies that intent and therefore eliminates the warning.
The alternative is to suppress the warning as the other answers mention. In your case, if the assumption is that the value should have been set via Reflection then this alternative seems reasonable if not preferable in such a case.

Suppressing "is never used" and "is never assigned to" warnings in C#

I have a HTTPSystemDefinitions.cs file in C# project which basically describes the older windows ISAPI for consumption by managed code.
This includes the complete set of Structures relevant to the ISAPI not all or which are consumed by code. On compilation all the field members of these structures are causing a warning like the following:-
Warning Field 'UnionSquare.ISAPI.HTTP_FILTER_PREPROC_HEADERS.SetHeader' is never assigned to, and will always have its default value null
or
Warning The field 'UnionSquare.ISAPI.HTTP_FILTER_PREPROC_HEADERS.HttpStatus' is never used
Can these be disabled with #pragma warning disable? If so what would the corresponding error numbers be? If not is there anything else I can do? Bear in mind that I only what to do this for this file, its important that I get see warnings like these coming from other files.
Edit
Example struct:-
struct HTTP_FILTER_PREPROC_HEADERS
{
//
// For SF_NOTIFY_PREPROC_HEADERS, retrieves the specified header value.
// Header names should include the trailing ':'. The special values
// 'method', 'url' and 'version' can be used to retrieve the individual
// portions of the request line
//
internal GetHeaderDelegate GetHeader;
internal SetHeaderDelegate SetHeader;
internal AddHeaderDelegate AddHeader;
UInt32 HttpStatus; // New in 4.0, status for SEND_RESPONSE
UInt32 dwReserved; // New in 4.0
}

Yes, these can be suppressed.
Normally, I'm opposed to suppressing warnings, but in this case, structs used for interop absolutely requires some fields to be present, even though you never intend to (or can) use them, so in this case I think it should be justified.
Normally, to suppress those two warnings, you would fix the offending code. The first ("... is never used") is usually a code-smell of leftovers from earlier versions of the code. Perhaps code was deleted, but fields left behind.
The second is usually a code-smell for incorrectly used fields. For instance, you might incorrectly write the new value of a property back to the property itself, never writing to the backing field.
To suppress warnings for "Field XYZ is never used", you do this:
#pragma warning disable 0169
... field declaration
#pragma warning restore 0169
To suppress warnings for "Field XYZ is never assigned to, and will always have its default value XX", you do this:
#pragma warning disable 0649
... field declaration
#pragma warning restore 0649
To find such warning numbers yourself (ie. how did I know to use 0169 and 0649), you do this:
Compile the code as normal, this will add some warnings to your error list in Visual Studio
Switch to the Output window, and the Build output, and hunt for the same warnings
Copy the 4-digit warning code from the relevant message, which should look like this:
C:\Dev\VS.NET\ConsoleApplication19\ConsoleApplication19\Program.cs(10,28):
warning CS0649: Field 'ConsoleApplication19.Program.dwReserved' is never
assigned to, and will always have its default value 0
Caveat: As per the comment by #Jon Hanna, perhaps a few warnings is in order for this, for future finders of this question and answer.
First, and foremost, the act of suppressing a warning is akin to swallowing pills for headache. Sure, it might be the right thing to do sometimes, but it's not a catch-all solution. Sometimes, a headache is a real symptom that you shouldn't mask, same with warnings. It is always best to try to treat the warnings by fixing their cause, instead of just blindly removing them from the build output.
Having said that, if you need to suppress a warning, follow the pattern I laid out above. The first code line, #pragma warning disable XYZK, disables the warning for the rest of that file, or at least until a corresponding #pragma warning restore XYZK is found. Minimize the number of lines you disable these warnings on. The pattern above disables the warning for just one line.
Also, as Jon mentions, a comment as to why you're doing this is a good idea. Disabling a warning is definitely a code-smell when done without cause, and a comment will prevent future maintainers from spending time either wondering why you did it, or even by removing it and trying to fix the warnings.

Another "solution" to fix these warnings is by making the struct public. The warnings are not issued then because the compiler can't know whether or not the fields are being used (assigned) outside of the assembly.
That said, "interop" components should usually not be public, but rather internal or private.

I got VS to generate the implementation skeleton for System.ComponentModel.INotifyPropertyChanged and the events were implemented as fields which triggered the CS0067 warnings.
As an alternative to the solution given in the accepted answer I converted the fields into properties and the warning disappeared.
This makes sense since the property declarations syntax sugar are compiled into a field plus getter and/or setter methods (add/remove in my case) which reference the field. This satisfies the compiler and the warnings are not raised:
struct HTTP_FILTER_PREPROC_HEADERS
{
//
// For SF_NOTIFY_PREPROC_HEADERS, retrieves the specified header value.
// Header names should include the trailing ':'. The special values
// 'method', 'url' and 'version' can be used to retrieve the individual
// portions of the request line
//
internal GetHeaderDelegate GetHeader {get;set;}
internal SetHeaderDelegate SetHeader { get; set; }
internal AddHeaderDelegate AddHeader { get; set; }
UInt32 HttpStatus { get; set; } // New in 4.0, status for SEND_RESPONSE
UInt32 dwReserved { get; set; } // New in 4.0
}

C/C++ users have (void)var; to suppress unused variables warnings.
#Pang in the comments reports that the variable discards can be used for warnings suppression:
_ = variable;
This is probably available since C# 7.0, that introduce such use of underscore in the language syntax. In previous versions of the language once could suppress unused variables warnings in C# with bitwise operators, for types where such operators are defined:
uint test1 = 12345;
test1 |= 0; // test1 is still 12345
bool test2 = true;
test2 &= false; // test2 is now false
Using such strategy is certainly fishy and to use as last resort. Better to upgrade language support and use variable discard syntax.

How to suppress a compiler warning in C# without using #pragma?

I need to suppress a specfic compiler warning in C#. Now I can do it like this:
#pragma warning disable 0649
private string _field;
#pragma warning restore 0649
Is there a way to do it like the following?
[SuppressCompilerWarning("0649")]
private string _field;
Because I only need to suppress warnings for this field, not a code block.
Note: I want to suppress the compiler warning, not the Code-Analysis warning.
Thanks!

Doesn't:
private string _field = null;
remove the warning as well?

No. You can do it project wide via a build flag, but otherwise a field is just another (small) block.
Of course, you could assign it a value somewhere... that'll make it happy ;-p (I'm assuming it is actually assigned a value via reflection or something?)

Ignore ObsoleteAttribute Compiler Error

I have an enumeration value marked with the following attribute. The second parameter instructs the compiler to error whenever the value is used. I want this behavior for anyone that implements my library, but I need to use this enumeration value within my library. How do I tell the compiler to ignore the Obsolete error for the couple of uses in my library.
public enum Choices
{
One,
Two,
[ObsoleteAttribute("don't use me", true)]
Three,
Four
}
Solution (Thanks everyone)
public class EnumHack
{
static EnumHack()
{
// Safety check
if (Choices!= (Choices)Enum.Parse(typeof(Choices), "Three"))
throw new Exception("Choices.Three != 3; Who changed my Enum!");
}
[Obsolete("Backwards compatible Choices.Three", false)]
public const Choices ChoicesThree = (Choices)3;
}

Private a separate constant somewhere like this:
private const Choices BackwardsCompatibleThree = (Choices) 3;
Note that anyone else will be able to do the same thing.

What about using #pragma to disable the warning around the specfic code?
#pragma warning disable 0612
// Call obsolete type/enum member here
#pragma warning restore 0612
A note to visitors, this only works with types and enum members. As far as I am aware, this will not work with other type members (e.g. methods, properties, etc).

What I see is that you're using this public enum for private logic, and after obsoleting it, you still need that logic internally.
I see 2 options:
Map it to a private Enum when you use it for your branching logic. You should be able to straight cast from one to the other.
Cast it from an int, thus never using the actual Enum value in your code.
As Jon points out above, anyone using your library can, and WILL (I know where you work), just hack through it anyhow.

It may not be the prettiest solution in the world, but you can try to trick the compiler by assigning values to the enum and then casting on your internal calls. For example this app runs:
namespace ConsoleApplication
{
class Program
{
static void Main(string[] args)
{
TestMethod((Choices)3);
}
private static int TestMethod(Choices choice) {
return 1;
}
}
public enum Choices
{
One = 1,
Two = 2,
[ObsoleteAttribute("don't use me", true)]
Three = 3,
Four = 4
}
}
I thought that Enum.Parse would work but it gets a run-time error, so don't do this:
(Choices)Enum.Parse(typeof(Choices), "Choices.Three")
I don't have experience with obsolete enums so I would recommend some pretty good testing around this.

TheSoftwareJedi correctly notes that this won't work with obsolete attribute set to be an error. The following "answer" only works when the obsolete notification is raised as a warning.
From Visual Studio you can do this on a per-project basis:
Go to the Project Properties page for the project you want to be able to suppress the obsolete warning on.
Go to the Build tab: Errors and Warnings : Suppress Warnings
Enter the warning number, 0612 in this case.
Other projects will continue to get the obsolete warning but this project will not. Note that this will disable ALL obsolete warnings.