DoDN Source & Presentation

Thanks for coming to Western Michigan's Day of Dot Net this past Saturday! The session went well, had some good questions about the configuration of a SharePoint developer's rig that I'll address in some detail in a subsequent post, but wanted to get this posted first. It's the presentation deck and the source code for the demos. The source code is all built for Visual Studio 2010. If you have access to the Expression Blend tools, all the better, but for the demos Visual Studio will definitely do the trick.


Here's the link to the zip file: DoDN-SharePoint-Silverlight.zip


Note that for the third demo, you'll need to host the compiled .XAP file in a SharePoint site that has a list named DayofDotNet. There's a .STP file (a SharePoint List Template file) you'll need to use to create this list, so that it has the fields & content the code is looking for. Post a comment or email me if you get stuck.


Thanks again for attending!


Steve & Charles

Visual Studio 2010 & Crystal Reports - change server at runtime

What? This isn't a SharePoint topic! You're right...every so often have to stretch a little bit.

So I have an ASP.Net web app and needed to add in a report. I didn't want to hand code it, and I had looked at using Crystal Reports for a different project & liked how nicely it integrates with Visual Studio. EZ-PZ to deploy it to the server, just install the runtime, deploy the project and we have reports!

Then came time to get the project up to production. I installed the runtime for Crystal Reports, clicked the Report link,and got the dreaded Database Login failed. Hmmm - I had updated the web.config appsettings to point to the Production SQL Server instead of my dev box.

That wasn't enough. Found a few entries suggesting to use the CrystalDecisions ConnectionInfo class, then another page saying to apply this change to all of the tables & subtables on the report, but that didn't help me - still got that logon error.

I ended up going the route of populating a data table with my report data, then using this table in the report - made things easier.

One other twist, I then needed to export this as a PDF, but I have SSL enabled; had to add in a few more lines of code. Take a look! And yes, this is VB.Net - it's an inherited project, too many lines to convert over!

Dim dt As DataTable

dt = BindReport()

rpt.SetDataSource(dt)

Dim reportDate As DateTime = Session("CurrentPayPeriod")

' Tell the browser this is a PDF document so it will use an appropriate viewer.
Response.Buffer = True
Response.ClearContent()
Response.ClearHeaders()
Response.ContentType = "application/pdf"


rpt.ExportToHttpResponse(ExportFormatType.PortableDocFormat, Response, False, "Timesheet Report")

Dim conString As String = System.Configuration.ConfigurationSettings.AppSettings("connectString")
Dim con As SqlConnection = New SqlConnection(conString)
con.Open()
Dim cmd As New SqlCommand("usp_GetReportData", con)
cmd.CommandType = CommandType.StoredProcedure
cmd.Parameters.Add("@SelectedDate", SqlDbType.Date).Value = CDate(Session("ReportPeriod"))
cmd.Prepare()

Dim sqlAdapter As SqlDataAdapter = New SqlDataAdapter(cmd)

Dim dtReport As DataTable = New DataTable()
sqlAdapter.Fill(dtReport)
con.Close()

Return dtReport
End Function

Summer 2010

Hard to believe it's the last official week of summer - school starts next Tuesday, back to the old schedule! And hard to believe my daughter's already a third grader, time goes by!

So what have I been up to lately? SharePoint 2010 architecture. Haven't done a ton of coding lately, but I have inherited an ASP.Net application and have another one in the works. Did some coding with Silverlight & the Client Object Model for 2010 - blog post coming - it is sweet.

COM (the new COM, that is) is an EXCELLENT way to continue to deploy code to SharePoint, but do so without having to bug your administrators or your Change Management team. The code runs on the client, so no consumption of server resources, and the code can do only what the user can do, so the risk of deleting all sites on the farm is minimized.

Have also been looking at multitenancy. This is going to be big with 2010 - being able to partition off multiple companies on the same set of hardware, w/o needing completely separate farms.

Look for more blog entries about all of the above...really...I promise...

Visual Studio 2010 web parts and the type could not be found or it is not registered as safe

Not the story I'll ready to my daughter tonight, but the tale of a rename gone bad. When you're creating a web part in SharePoint 2010, and you rename your items from VisualWebPart1 to MyCoolWebPart, perform a Search in the Entire Solution scope for any remaining remnants of VisualWebPart1. There were a few...fix them up and your web part will register safely just fine & you'll be able to add it to your web part page.

SharePoint Saturday, speaking on workflow

It has been so busy it's about time I've reported this! I'm giving a talk at SharePoint Saturday in Ann Arbor on 3/13. The talk will be the SharePoint 2010 Workflow Smackdown. We'll be taking a look at SharePoint Designer 2010 & see if it's a contender for building workflows, compared to Visual Studio 2010.

As a developer, my first inclination is to go to the 'real thing', crack open Visual Studio and build out a new workflow project. But if my administrator won't let me deploy custom code, then what? In the 2007 days it would be worth the battle; we could create workflows in SPD 2007 but seemed it was always one action short of what I needed.

So can SPD 2010 help out? In short, yes! It has a lot more capability for workflow development, but I think more importantly it is a tool a (knowledgable) end user could use. Especially with Visio 2010 as the workflow designer tool, never did like trying to lay out the workflow in SPD 2007, wasn't visual enough.

Of course, that does mean that user needs Visio 2010, and SPD 2010. SPD 2010 will still be free, but Visio of course is licensed.

Now, if your environment lets you deploy custom code, and you know your way around .Net development, should you even bother with SPD? Good question. I'd have to vote it is worth considering, from a maintenance standpoint. One of the things us developers always do (me too!) is to create some great crazy code, deploy it, it works, great, and we move on. But then down the road darn that thing, it's having a problem. With SPD, because it is declarative, debugging and/or modifying is easier...in fact you could even get that power user to take over! So it is something to consider.

With that - here's the link to the presentation: SharePoint Saturday Workflow Smackdown

Note that if you want to play around with workflows, I recommend making sure you've first enabled the User Profile Import Service - without it, if you assign a workflow item & wait for the approval to kick in, you'll get a nice REJECTED instead. No email address. I also use SMPT4DEV to test the email messages - much easier than standing up Exchange! It's really handy.

Access Denied with SP custom web service

This one was bugging me for a while! I have an application that has a SharePoint workflow, that then calls a custom web service that interacts with the SP object model (long story...has to do with credentials).

Things were working fine until of late I started getting Access Denied messages when invoking a web service. In particular, the web service would fail when I tried to intantiate a web object, either through .RootSite or .OpenWeb(). I tried all sorts of combinations of Information Policy settings in Central Admin, switching to a different app pool account in IIS, impersonation in the code, you name it.

Now, the curious thing was it appeared the 401 Access Denied message was coming from IIS, not from SharePoint. I could attach to the debugger, and my code definitely was being executed, just failing at that .RootSite/.OpenWeb call. More curious, switching from Integrated Autheticatio to Anonymous allowed the web service call to work fine.

Well, I found a reference to an issue introduced by the .Net 3.5 SP1 Framework with the loopback adapter. Since the web service and the workflow were executing on the same server, I think it was the Framework that was causing the problem, too many repeat calls to the same server. When I changed the URL for my web service from http:// to http://localhost, the service ended up working fine. Repeated on a second server hosting the same instance.

Time to update the deployment documentation!!

And, happy 2010! Learned PowerShell yet?