Don't enclose the parameters placeholders with single quotes. In that way they becomes simply string literals and your query can't work

 string querystr = "UPDATE Users SET User_FirstName=@User_FirstName, " + 
                   "User_LastName=@User_LastName WHERE User_ID=@User_ID";

Another thing to consider. Are you sure that your User_ID field is a string (text, nvarchar, varchar) field in the database?. If it is a numeric field then you need to convert the value passed as parameter for that field to a numeric value (I.E. Use Convert.ToInt32)

So, if this is true, the code could be changed as

string User_ID = Session["ID"].ToString();
string User_FirstName = FirstNameEdit.Text;
string User_LastName = LastNameEdit.Text;

query.Parameters.AddWithValue("@User_ID", Convert.ToInt32(User_ID));
query.Parameters.AddWithValue("@User_FirstName", User_FirstName);
query.Parameters.AddWithValue("@User_LastName", User_LastName);
query.ExecuteNonQuery();

I have used the AddWithValue following the recommendation in MSDN that says

AddWithValue replaces the SqlParameterCollection.Add method that takes a String and an Object. The overload of Add that takes a string and an object was deprecated because of possible ambiguity with the SqlParameterCollection.Add overload that takes a String and a SqlDbType enumeration value where passing an integer with the string could be interpreted as being either the parameter value or the corresponding SqlDbType value. Use AddWithValue whenever you want to add a parameter by specifying its name and value.

However, the advantage in the implicit conversion it's also the disadvantage since the conversion may not be optimal. I can give as reference this very thorough article

Don't enclose the parameters placeholders with single quotes. In that way they becomes simply string literals and your query can't work

 string querystr = "UPDATE Users SET User_FirstName=@User_FirstName, " + 
                   "User_LastName=@User_LastName WHERE User_ID=@User_ID";

Another thing to consider. Are you sure that your User_ID field is a string (text, nvarchar, varchar) field in the database?. If it is a numeric field then you need to convert the value passed as parameter for that field to a numeric value (I.E. Use Convert.ToInt32)

So, if this is true, the code could be changed as

string User_ID = Session["ID"].ToString();
string User_FirstName = FirstNameEdit.Text;
string User_LastName = LastNameEdit.Text;

query.Parameters.AddWithValue("@User_ID", Convert.ToInt32(User_ID));
query.Parameters.AddWithValue("@User_FirstName", User_FirstName);
query.Parameters.AddWithValue("@User_LastName", User_LastName);
query.ExecuteNonQuery();

I have used the AddWithValue following the recommendation in MSDN that says

AddWithValue replaces the SqlParameterCollection.Add method that takes a String and an Object. The overload of Add that takes a string and an object was deprecated because of possible ambiguity with the SqlParameterCollection.Add overload that takes a String and a SqlDbType enumeration value where passing an integer with the string could be interpreted as being either the parameter value or the corresponding SqlDbType value. Use AddWithValue whenever you want to add a parameter by specifying its name and value.

However, the advantage in the implicit conversion it's also the disadvantage since the conversion may not be optimal. I can give as reference this very thorough article

Another note to keep in mind. Do not swallow exceptions. In your code, the generic message that advise the user of a failure is not enough to let you understand what's going wrong. You should replace your code with

try
{
   ......
}
catch(Exception ex)
{
      // I let you translate... :-)
      StatusMessage.Text = "Noget er galt, prøv lidt senere "  + 
                           "Error message=" + ex.Message;
}

Don't enclose the parameters placeholders with single quotes. In that way they becomes simply string literals and your query can't work

 string querystr = "UPDATE Users SET User_FirstName=@User_FirstName, " + 
                   "User_LastName=@User_LastName WHERE User_ID=@User_ID";

Another thing to consider. Are you sure that your User_ID field is a string (text, nvarchar, varchar) field in the database?. If it is a numeric field then you need to convert the value passed as parameter for that field to a numeric value (I.E. Use Convert.ToInt32)

Don't enclose the parameters placeholders with single quotes. In that way they becomes simply string literals and your query can't work

 string querystr = "UPDATE Users SET User_FirstName=@User_FirstName, " + 
                   "User_LastName=@User_LastName WHERE User_ID=@User_ID";

Another thing to consider. Are you sure that your User_ID field is a string (text, nvarchar, varchar) field in the database?. If it is a numeric field then you need to convert the value passed as parameter for that field to a numeric value (I.E. Use Convert.ToInt32)

So, if this is true, the code could be changed as

string User_ID = Session["ID"].ToString();
string User_FirstName = FirstNameEdit.Text;
string User_LastName = LastNameEdit.Text;

query.Parameters.AddWithValue("@User_ID", Convert.ToInt32(User_ID));
query.Parameters.AddWithValue("@User_FirstName", User_FirstName);
query.Parameters.AddWithValue("@User_LastName", User_LastName);
query.ExecuteNonQuery();

I have used the AddWithValue following the recommendation in MSDN that says

AddWithValue replaces the SqlParameterCollection.Add method that takes a String and an Object. The overload of Add that takes a string and an object was deprecated because of possible ambiguity with the SqlParameterCollection.Add overload that takes a String and a SqlDbType enumeration value where passing an integer with the string could be interpreted as being either the parameter value or the corresponding SqlDbType value. Use AddWithValue whenever you want to add a parameter by specifying its name and value.

However, the advantage in the implicit conversion it's also the disadvantage since the conversion may not be optimal. I can give as reference this very thorough article