We Keep Coding

Is this really a simplification?

So I have a pretty simple class with an Id field, and the Id can be set in the constructor.
Typically I will use this to clearly identify the class property as opposed to the method argument. To me this seems clearer.
IDE0003 wants me to remove the this, with the message 'Name can be simplified', is that correct?
This seems less clear to me, and also allows a casing error to easily result in id = id.

This other question has an answer that says you can configure the editor to remove the behavior. Personally I like "this"
Tools > Options > Text Editor > C# > Code Style and check Qualify member access with 'this'
Visual Studio 2015 - Change Light Bulb, Quick Action settings

The this keyword almost always is unnecessary, see When do you use the "this" keyword?.
allows a casing error to easily result in id = id
That will yield another warning on its own:
Assignment made to same variable; did you mean to assign something else?

If you use General Naming Conventions then the this keyword is redundant because the parameter should be id and the property should be Id based on Naming Guidelines. So it seems clear:
public int Id
{
get;
private set;
}
public VSOMessage(int id)
{
Id = id;
}
Please note that the guidelines itself don't say, to use or not use this keyword but because C# is case sensitive, it would be a simplification to remove this keyword but when you don't use Naming Conventions then you may naming the property id instead ofId so you should use this keyword in such cases.

If you want to prevent the warning in code rather then updating Visual Studio settings, use the SuppressMessage data annotation, which will prevent the warning.
It looks something like this:
[SuppressMessage("Reason #Enter whatever you'd like", "ID, must match what intellsense is showing it looks something like this: IDE0001", Justification = "(optional, your own description")]
Here is an exact example for your "this" variable situation:
[SuppressMessage("IntelliSenseCorrection", "IDE0003", Justification = "Allowing usage of 'this' keyword to maintain consistency/readability of code.")]

Change Content Attribute

I'd like to create an attribute to change the content of the property.
[CleanContent]
public string address {get;set;}
address = "hello world ";
address would change to "hello world"
I've used ValidationAttribute, anyone know if I can get Attributes can do this?

Attributes aren't "active" - they are just metadata, and don't do anything unless some calling framework checks for them via reflection and then deliberately does something like invoking a method on them. So no, you can't do this.
Caveat: IL-rewriting tools like post-sharp also use attributes, but they behave in a very different way (by using the attributes to help it re-write the IL after compilation).

You could use attributes to mark what properties you want to clean, but they won't clean it themselves, you need something to call them.
Below is a question closely related to what you are asking, and it provides a few ideas:
Trim all string properties

Add code to C# get/set of property without needing backing field?

You know how you can have a property that automatically generates a backing field? Like if I go:
public String SomeProperty {get; set;}
I know that if I want to add code to that property I have to create the backing field as so:
public string someProperty = string.Empty;
public string SomeProperty
{
get { return someProperty; }
set
{
someProperty = value;
DoSomething();
}
}
Basically, what I want to know is... is there any way to do this but without having to create the backing field? For example I could use it to trigger some kind of event that occurs when a property is set. I'm looking for something like this:
public string SomeProperty
{
get;
set { this.OnSomeEvent; }
}
But I know that'll cause a compile error because get needs do declare a body if set does.
I've researched and I cant find anything, but I thought I'd check to see if anyone knew.
I guess what I'm really after is some way to trigger an event when a property is changed but without having to add all that extra clutter. Any suggestions?

Simple answer is no, you can't have it both ways. From .NET Docs:
In C# 3.0 and later, auto-implemented properties make property-declaration more concise when no additional logic is required in the property accessors.

There are not any solutions for this built into the framework, and you cannot modify existing types via reflection (in order to add the logic at runtime). The only way to accomplish this seems to be at compile time.
There is a product http://www.postsharp.net/ that can accomplish this (intercept property/method calls), and there does appear to be a free edition.

The field keyword might be added to C#, see https://github.com/dotnet/csharplang/issues/140, which removes "when no additional logic" requirement for auto properties.
It didn't make it into C# 10 nor 11, but latest comment from compiler team says C# version 12 might have it. They release yearly, so that would be Nov 2023.

Is it possible to create this linq statement dynamically?

I'm creating a rule validation class - nothing fancy.
I want to set properties like this:
public int MaxLoanAmount { get; set; }
The data would be validated like this. _app refers to data injected via the constructor.
bool MaxLoanAmountValid
{
get { return _app.LoanAmount >= MaxLoanAmount; }
}
I could construct some if logic to test if each of my properties are set, validate them and return the result, however I would like to try and be a little more clever than that.
I wonder if it is possible to build a dynamic expression, so when MaxLoanAmount is set, I add "MaxLoanAmountValid", and so on "MaxLoanAmountValid AND MinLoanAmountValid" etc.
Thanks in advance.

Yes, you can dynamically build a Linq expression tree either using the .NET APIs or one of several free tools that make the job easier. Some can parse a string into an expression, so all you have to do is build the string. See the links in the answer to an almost identical question: Dynamically Build Linq Lambda Expression
If you want to be even more "clever" you may get dynamically the current property name in its Set method using Reflection like this MethodBase.GetCurrentMethod().Name.

Why doesn't XElement have a GetAttributeValue method?

Sometimes I'd like to know the reasoning of certain API changes. Since Google hasn't helped me with this question, maybe StackOverflow can. Why did Microsoft choose to remove the GetAttribute helper method on XML elements? In the System.Xml world there was XmlElement.GetAttribute("x") like getAttribute in MSXML before it, both of which return either the attribute value or an empty string when missing. With XElement there's SetAttributeValue but GetAttributeValue wasn't implemented.
Certainly it's not too much work to modify logic to test and use the XElement.Attribute("x").Value property but it's not as convenient and providing the utility function one way (SetAttributeValue) but not the other seems weird. Does anyone out there know the reasons behind the decision so that I can rest easily and maybe learn something from it?

You are supposed to get attribute value like this:
var value = (TYPE) element.Attribute("x");
UPDATE:
Examples:
var value = (string) element.Attribute("x");
var value = (int) element.Attribute("x");
etc.
See this article: http://www.hanselman.com/blog/ImprovingLINQCodeSmellWithExplicitAndImplicitConversionOperators.aspx. Same thing works for attributes.

Not sure exactly the reason, but with C# extension methods, you can solve the problem yourself.
public static string GetAttributeValue(this XElement element, XName name)
{
var attribute = element.Attribute(name);
return attribute != null ? attribute.Value : null;
}
Allows:
element.GetAttributeValue("myAttributeName");