locked
Issue with the property declaration in cs file

    Question

  • Hi,

          I am using Visual Studio 2010 and FxCop 1.36. While I am running FxCop I am getting the following error. Can any one help me out to fix this error.

      'CA2116 : Microsoft.Security : The method 'AddTaskWPUserControl.AddTaskData.get()' is defined in an assembly that has AllowPartiallyTrustedCallersAttribute and calls 'Task.TaskStatus.set(string)', which is defined in an assembly ('CIG.UMS.ePAS.UI.Model.dll') that does not. Review the called methods to ensure they cannot be used in a destructive manner if called by malicious code.'

                I am using the below .cs file code.

    public partial class AddTaskWPUserControl : UserControl, IAddTasks
        {
            #region Defining Page_Init region
    
            private AddTaskPresenter presenter;
            private int taskId;
            Task task = new Task();
            ErrorDetails errorDetails = new ErrorDetails();
            List<NoteType> lstNoteType = new List<NoteType>();
            List<Branch> lstBranchData = new List<Branch>();
            List<Staff> lstStaffData = new List<Staff>();
            private string m_LoginAd;
            private int m_branchId;
            private bool m_result;
            private string m_ResultStatus;
            protected override void OnInit(EventArgs e)
            {
                base.OnInit(e);
            }
    
            #endregion
    
            #region Defining Property Values
    
            /// <summary>
            /// This property returns Task information
            /// </summary>
            public Task AddTaskData
            {
                get
                {
                    task.TaskAssignedBy = txtAssignedBy.Text;
                    task.TaskAssignedByLoginID = UMSUtility.GetLoginName();
                    task.TaskDateAssigned = DateTime.Now;
                    task.TaskStatus = cmbStatus.SelectedItem.Value;
    
                    task.TaskAssignedTo = cmbAssignedTo.SelectedItem.Text;
    
                    RadTreeView tree = (RadTreeView)cmbAssignedTo.Items[0].FindControl("BranchTreeView");
                    if (tree.SelectedNode != null)
                    {
                        task.TaskAssignedToLoginID = tree.SelectedValue;
                    }
    
                    if (tlrDate.SelectedDate != null)
                    {
                        task.TaskDueDate = tlrDate.SelectedDate.Value;
                    }
    
                    if (cmbTaskType.SelectedItem != null)
                    {
                        task.TaskType = cmbTaskType.SelectedItem.Value;
                    }
                    else if (cmbTaskType.Text != null)
                    {
                        task.TaskType = cmbTaskType.Text;
                    }
                    task.TaskDescription = txtNotepad.Content;
    
                    return task;
                }
                set
                {
                    if (value.ErrorInformation.ErrorStatus)
                    {
                        UMSUtility.AssignErrorMessage(value.ErrorInformation.ErrorDescription, this.Page);
                    }
                }
    
            }
    
            /// <summary>
            /// This property binds list of data to TaskType combobox
            /// </summary>
            public List<NoteType> TaskTypeData
            {
                set
                {
                    if (value.Count > 0)
                    {
                        if ((value[0].ErrorInformation == null) || (value[0].ErrorInformation != null && value[0].ErrorInformation.ErrorStatus == false))
                        {
                            cmbTaskType.DataSource = value;
                            cmbTaskType.DataBind();
                            ViewState["lstNoteType"] = value;
                        }
                        else
                        {
                            UMSUtility.AssignErrorMessage(value[0].ErrorInformation.ErrorDescription, this.Page);
                        }
                    }
    
                }
                get
                {
                    lstNoteType = (List<NoteType>)ViewState["lstNoteType"];
                    return lstNoteType;
                }
            }

     The same error shows for the set and get methods of TaskAssignedByLoginID, TaskAssignedTo, TaskDescription, etc. Can anyone help me to solve this issue.

    Thanks 

    Vijay

    Sunday, March 18, 2012 5:25 PM

All replies

  • The simplest solution is to sign your project with a strong name.

    The slightly less simple method is to review the code and apply the suppression.

    The least simple method is to not call trusted code from the partially trusted (usually meaning not-stronly-named) assembly and thus placing hte functionality elsewhere.


    My blog: blog.jessehouwing.nl

    Sunday, March 18, 2012 10:03 PM
  • Hi Jesse,

            Can you please a bit elaborate on second and third point(i.e below)

    The slightly less simple method is to review the code and apply the suppression.

    The least simple method is to not call trusted code from the partially trusted (usually meaning not-stronly-named) assembly and thus placing hte functionality elsewhere.

             If you give a small examples that will be very helpful for me.

    Thanks

    Vijay

    Monday, March 19, 2012 6:34 AM
  • The warning is purely to ensure you're aware that you're potentially exposing trusted code through your untrusted project. So if you've reviewed it manually and concluded that you're not exposing any important methods or interfaces in an untrusted fashion, then you can use the "Suppress Message in Source" option to ignore the warning.

    Another option is to make your calling code (thus the code that currently has the warnings) trustable. If you sign the assembly with a strong name it will no longer be considered Partially Trusted, and the warnings will all go away.


    My blog: blog.jessehouwing.nl

    Monday, March 19, 2012 9:33 AM
  • Which version of the .NET Framework are you targeting when you compile?  Also, have applied any of the following attributes to either assembly or any of the code in either assembly?

    • SecurityTransparentAttribute
    • SecurityCriticalAttribute
    • SecurityRulesAttribute
    Monday, March 19, 2012 12:28 PM
  • The warning is purely to ensure you're aware that you're potentially exposing trusted code through your untrusted project.

    Actually, the intent of the rule is pretty close to the the exact opposite of this.  The potential security hole that the rule detects is something that occurs when the APTCA assembly runs with high trust (i.e.: the APTCA assembly is not "untrusted").  The concern is that it might be exploited by a low-trust caller, not that the APTCA assembly that is being analyzed by the rule might itself do something "bad" even with a restricted permission grant.

    Another option is to make your calling code (thus the code that currently has the warnings) trustable. If you sign the assembly with a strong name it will no longer be considered Partially Trusted, and the warnings will all go away.

    This won't work.  APTCA is usually applied to assemblies that are already strongly named, even if this isn't always the case.  Either way, the reason one applies APTCA to an assembly is to allow partially trusted callers to invoke its code despite the fact that it is fully trusted.   In other words, what you're suggesting is essentially rolling back the effect of APTCA entirely.  If this was desired, the simplest approach would be to simply remove the APTCA instance from the assembly.  However, if the effect of APTCA is actually necessary in any given case, this wouldn't be a particularly great way of addressing the CA2116 violation.  (There are actually some more effective mechanisms available than simply suppressing every violation, but these depend on the target .NET Framework version and the security transparency level of the assembly.)

    Monday, March 19, 2012 12:50 PM
  • Nicole, we're getting mixed up here. My original statement was meant to say what you're trying to explain.

    But these kinds of things always turn out to be very hard to explain :S without pictures and loads of text.

    The up to date documentation which explains the rule can be found here:

    http://msdn.microsoft.com/en-us/library/ms182297(v=vs.100).aspx 

    And here (similar rule, different CA number):

    http://msdn.microsoft.com/en-us/library/ms182298.aspx

    The proper solution is found there as well, but dives into permission demands and other things as well, which is one of the hardest parts of the .NET framework to understand.


    My blog: blog.jessehouwing.nl

    Monday, March 19, 2012 12:58 PM
  • Jesse,

    Unfortunately, both the CA2116 and CA2117 help topics seem to have slipped under the radar wrt updates that should have been applied when the security transparency model was introduced (and then changed).  The recommended fixes are pretty much just plain wrong for .NET 4.0, and they're incomplete for .NET 2.0 through 3.5.  If you're interested in the details of APTCA behaviour since the introduction of the transparency model, http://blogs.msdn.com/b/shawnfa/archive/2009/11/12/differences-between-the-security-rule-sets.aspx would be a much better source than the FxCop rule docs.

    Nicole

    Monday, March 19, 2012 1:56 PM
  • Hi Jesse and Nicole,

    Thank you for your active participation in the MSDN community!

    Hi Vijay,

    Did these replies resolve your problem?

    You could mark the answer if they did then I will close this thread, if not please post the latest situation of this issue.

    Best Regards,


    Jack Zhai [MSFT]
    MSDN Community Support | Feedback to us

    Friday, March 23, 2012 5:07 AM
    Moderator