We developed a simple Inventory Tracking SharePoint site for the I.T. department to...well...track inventory. I set this site up using Microsoft's Inventory Tracking site template in SharePoint. All was going well.
The first glimpse of an issue was when the person coordinating the inventory noticed the pricing on the items was incorrect. Through a little trial and error, I discovered that the issue was the dropdown lists.
Observe:
Now when the user selects a customer in the second dropdown list the numbers for the selected item change even though the item has not changed.
So here is the original issue: Why doesn't the form hold on to the correct number?
The answer to that is somewhat simple, but I do not have a resolution to it. My resolution was to build a custom form. The issue with the default SharePoint form is that both dropdowns are tied to lists with more than 19 items.
Marc Anderson of Sympraxis Consulting let me know, "
- When there are fewer than 20 options, SharePoint renders the control as a plain old select. If the column value is not required, there is an empty value at the top of the list. (I call these Simple dropdowns.)
- When there are 20+ options, SharePoint gets all helpful and renders the control as an input field. Then, when you either type in the input field or click on the dropdown image, it dynamically creates a select with the options. If the column value is not required, there is an (None) value at the top of the list. (I call these Complex dropdowns.) "
What I did was develop a custom input form for new transactions to replace Microsoft's form. A simple custom aspx page with standard asp labels, buttons, textboxes and dropdown lists. I made use of the SPDataSource for the dropdown lists. I also used the ajax toolbox for the calendar control. Pretty straightforward stuff.
So here comes my next learning opportunity. We are fairly new to SharePoint development. We noticed that there were certain functions we were constantly having to have in our SharePoint development projects. So I worked with another developer to create a small, but ever growing, SharePoint library of common functions. When deployed, we ran into an issue with trust.
With the helper dll referenced in our custom ASPX form, SharePoint generated a Security Exception.
So we found that the helper dll needed to have a few key pieces of information to allow it to be called. We added an attribute to the class and added the "AllowPartiallyTrustedCallers" to the assembly info.
So now we have the helper dll in the GAC and the dll for the form in the bin. I create a custom folder for the aspx form, but that's just my style. Others on the web will have a different opinion. The form now works. No error and the transaction is created.
So we're done, right? Wrong. Look at the workflows for the transaction. None of them started.
So, on to the next learning opportunity.
Why do the workflows not fire? In the log I could not find any concrete information on what the actual issue was. We have another custom aspx form in another site that works fine without any issues with the workflows. So I looked into the differences between the two.
We maintain a custom security policy file. It is a customized version of the wss_mediumtrust.config file. Thanks to Tyler Holmes' blog, System.What, I found that I needed to add a line for this new dll.
< CodeGroup class="UnionCodeGroup" version="1" PermissionSetName="FullTrust">
< IMembershipCondition class="StrongNameMembershipCondition" version="1" PublicKeyBlob="{InsertPKBlob}">
< /CodeGroup >
This apparently gives the dll a full trust permission.
Now all is working well, but I do plan to spend a lot of time in the near future learning all I can about CAS.
This was an adventure for me. I have always believed that just dumping your dll's into the GAC was not the best practice. It may work for testing and development, but I do not believe it is a long term solution. I believe creating a custom security policy, while more work, creates a more stable and secure environment. That belief was certainly challenged on this project, but in the end I believe now more than ever that it is possible to not put everything in the GAC. Sometimes it does make sense, like with our helper dll, but form specific dll's do not have to be put in the GAC.
I would like to thank everyone who has indirectly helped me on this, but that is far too many blogs to remember all those who contributed. Specifically, I do spend a lot of time on and give a lot of credence to Andrew Connell's blog. He is an excellent source for all things SharePoint.
I hope this helps you. Sorry about some of the spacing. It doesn't look like that when composing, it shows that way after posting.
No comments:
Post a Comment