Multi-Line Text Field Displays div Tag

I ran into this little annoyance today.

When adding a multi-line text field to a SharePoint list and manually adding the field to a display form, it shows the HTML tag.

It is a very simple fix.  I found it by creating a test list with a multi-line column and then viewing the source in SharePoint Designer.  The fix is to add a 'disable-output-escaping="yes"' to the '< value-of select="@Notes">' field.

After I discovered the fix, I did find this post as well from the SharePoint Designer Team Blog
SPD Team Blog on Using Disable Output Escaping In Data View

Hope this helps.

Code Access Security

I wasn't sure what to title this post at first. My original project turned into such a learning adventure that I wasn't sure what title would be appropriate.  I finally decided on Code Access Security (CAS) because I believe it is the root skill that would've applied most.

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.) "    

The problem with this is that Microsoft makes use of a javascript function getTagFromIdentifier in which you pass in a tagName, Identifier, and Title.  Since both fields are now input fields, when it calls this function the second time, it grabs the customer index and applies it to the inventory item array and changes the price and quantity to the values for the item at the index equal to the selected customer index.  Since this form makes use of the list form, I don't see a way to fix this.  Royal pain.  Thanks Microsoft!  You can workaround by selecting the item second.  Somebody smarter than me could probably also have the script only work on the first dropdown list.

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.

SharePoint Not Logging

I ran into an issue today I thought I would share.  Adding an item to a SharePoint list is causing the workflows to "Failed to Start (retrying)".  When I went to the LOGS folder in the 12 hive to investigate, there were no logs.  I double checked and reset all the setting in the CA, but still was unable to get any logging in SharePoint.

Finally, I double checked the Path setting under the Trace Log section.  There was a space at the end of the path.  Instead of ...\12\LOGS.  It was ...12\LOGS.  I removed the space, saved the screen, and ta dah!!!  I have logs.

I'm not sure how that stupid space got in there, but that was causing my logging to not work.

Hope this helps you if you are having a similar issue.