views:

29

answers:

3

We have a handful of sharepoint sites that uses various UserControls we have developed for custom stuff including authentication and authorization. On one of these sites when a new user is created by an admin it creates a password of this minumum length number of characters, saves the user info and sends an email to the users email address. All was well until.... Corporate just handed down a new policy that all users must use a 10 character minumum length password vs the previous 8. This valus is in an assembly in a static class so we can do something like

//Assembly 1 defines rules and logic

public static class AccountRules
{
    public static int PasswordMinimumLength = 10;
}


//Assembly 2 calls references Assembly 1

Status CreateUser(User u)
{
    if (u.Password == null)
    {
        u.Password = GeneratePassword();
    }

    return DAL.SaveUser(User);

}


string CreatePassword()
{
   string pass = "";
   for (int i = 0; i < AccountRules.PasswordMimimumLength; i++)
   {
      pass += RandomChar();
   }
}

We updated the assembly that contains this constant, rebuild dependent sites and published controls to the dev servers. Now I create a new account and its still making 8 character passwords! I check the assembly with reflector and the constant length is 10. I removed this assembly from the GAC and reinstalled the new one with the 10 charater minumum and still generating 8 char passwords. We restarted the site in IIS with no luck, the sharepoint app pool, the entire IIS instance, the physical box and still 8 character passwords. Where else is the dll possibly cached that this is happening? I'm ripping my hair out on this one. Thanks in advance for any help from you god-like experts.

A: 

You have a few things that you can do to help try to track this down.

  1. Make sure that it isn't copied locally to the /bin folder of your application
  2. Use Fusion Log Viewer to see what is actually being bound

More than likely the Fusion Log Viewer will get you what you need.

Mitchel Sellers
Thanks for the answers all. Not being too familiar with the GAC the fusion log viewer helped. The problem ended being that the value was coming from the GAC (vs the dll in the bin folder, which is why it worked when this dll was deleted) and was aided by some poor communication between my team and I.
teabaggs
I'm glad it helped! If this lead you to your answer, it would be nice to accept the answer as well so others know what helped!
Mitchel Sellers
A: 

Try removing the "Assembly 1" from GAC and see if you get an error or not. If you do get errors, your code is being loaded from GAC. Otherwise, it is loaded from somewhere else.

If it is a DEV server, you can add an extra line after your call to GeneratePassword() and write the path of "Assembly 1"into some trace log. What you have to trace is typeof(any type name from Assembly 1).Assembly.Location.ToString()

A side note: I would not call it a classical "dll-hell" problem, as it is used when problems arise due to versioning of libraries.

naivists
+1  A: 

I'm not sure exactly how customised your authentication system is. Usually I would expect the find the minimum password length restriction in the web.config inside the membership definition. If you're using some sort of membership model, then thats the first place I would check. (In a nutshell: Maybe its not your DLL defining the minimum password length even though someone has put a constant there!)

Zeb
this: (In a nutshell: Maybe its not your DLL defining the minimum password length even though someone has put a constant there!)
brian brinley