Code Camp: Creating .NET Solutions using OSS

On April 8’s Southwest Pennsylvania’s Code Camp I presented on creating .NET solutions using open source software (OSS). The demonstration went quite well and I received a very generous response from the audience. Thanks to all who attended and made this first Code Camp quite a success!

The premise of the presentation was to demonstrate that it is completely possible to create .NET solutions (specifically an ASP.NET web application) using free and open source tools. I used a GNU/Linux based laptop (Ubuntu) with the following tools:

  • Mono (gmcs compiler)
  • MonoDevelop
  • DBDesigner
  • Dia
  • OpenOffice.Org (Writer and Impress)
  • GNUnit2

The result of the demonstration was that while it is entirely feasible to live in a .NET world with all free and open source tools your efficiency will not make up (YET!) for the cost of a more integrated and mature toolset. However, the tools I used are progressing rapidly and there is no reason why they can’t benefit you now and in the near future. I would recommend evaluating the cost of ownership ranging through your server environment, development environment and office environment.

The slides, code and documents are all freely available for download here. Use them however you want (at your own risk, of course ).

If you have any questions or comments please feel free to drop a comment on this entry!

Advertisement

SharePoint Redirect using only IIS

Here is a quick solution to an small issue we had here at work…

One of our internal users (of our SPS instance) wanted to redirect an old list to a new list. I did not want to create a code-based solution (e.g. an aspx page, et al) and with the friendly "Apache could do this" jabbing I got from this guy I decided to see if IIS would handle it. And it did … really easy:

Example:
Redirect http://mysite/sites/Department/IT/oldlist to http://mysite/sites/Department/IT/newlist

  1. On the filesystem in your webroot, create a folder structure mimicking the URL:
    c:inetpubsharepointrootsitesDepartmentIToldlist
  2. Open IIS Management console and locate that folder
  3. Right-click on that folder and select properties
  4. Use the "A redirection to a URL" option in the Directory tab
  5. Enter the new URL (absolute OR relative) in the Redirect To: box
  6. Test it

All other sites in that path should remain untouched by IIS but since IIS processes this redirection prior to running the ISAPI filter/extension (e.g. SharePoint) then there is no need to even unmange this path from within SharePoint itself.

Simple. Clean. Quick. Even an Admin can do it!

Southwest Pennsylvania Code Camp

On April 8, 2006, we will be having the first (as far as I know) Code
Camp in Pittsburgh. As both an organizer as well as a presenter,
I encourage everyone in the area to attend this free event.

There are no corporate sponsors and all of the presenters are from the
community doing presentations and demos for the community. There
will be free lunch (I think) and plenty of free information!

For more information, please check out the Code Camp website:
http://www.pghdotnet.org/CodeCamp/default.htm.

My presentation will be on creating .NET solutions using free/open
source tools! It was interesting to create the demo so I hope
that remains when I actually give the presentation.

Getting and Setting a SecureString in .NET 2.0

SecureString Class
A nice new addition to the .NET 2.0 Framework is the SecureString class making it safe to store sensitive information in memory (e.g. passwords, connection strings). This class takes care of encrypting this information but the class does not provide a very straightforward method for getting and setting its value.

Since the actual value of the string is NOT stored in the memory space of your process it is not really a "managed" value so a bit of marshaling is required to work with it.

Setting a SecureString’s value
Fortunately, it is rather easy to set the value of a SecureString … but it has to be character by character. I assume the reason for this is because you really should not be using any transient/temporary variable to load the data into the SecureString. That would pretty much defeat its purpose. However, there will come a time when you want to set the value of the SecureString FROM another string. That much is simple:

SecureString securePassword = new SecureString();
string insecurePassword = "password";

foreach(char passChar in insecurePassword.ToCharArray()) {
    securePassword.AppendChar(passChar);
}



The above code simply iterates through the characters in the string and appends them to the SecureString.

Getting a SecureString’s value
It is as difficult, however, to retrieve the value from a SecureString as it was simple to set it. Since the value of the SecureString is not in the application’s process space your code has to interact with it via a pointer to a BSTR:

IntPtr passwordBSTR = default(IntPtr);

try {
    passwordBSTR = Marshal.SecureStringToBSTR(securePassword);
    insecurePassword = Marshal.PtrToStringBSTR(passwordBSTR);
} catch {
    insecurePassword = "";
}

This code uses the Marshal static class to retrieve the value of the SecureString into a BTRS and returns its pointer. Next, again using the Marshal class to reads the BSTR into a managed string vairable to be used at will.

Is this secure?
No … not really. It should be apparent by now that you are taking the value out of a secure, encrypted memory location and putting it right back into an insecure, unencrypted location.

SQL 2005 Reporting Services and Sharepoint Web Services

Introduction
One nice addition to SQL 2005 Reporting Services is the ability to have a XML Data Source (e.g. Web Service). However, getting it to work seems to be a little trickier than need be, especially for SharePoint’s web service.

The Problem
Following the example in the SQL Books Online makes it look like you can apply it to just any web service but you’ll end up fighting with the parameters if you do as they simply don’t get properly serialized. After researching the issue and combining several different answers it comes down to the XmlDP Query syntax. The syntax which works looks like this (using GetList as an example):

<Query>
   <Method Namespace="http://schemas.microsoft.com/sharepoint/soap/&quot;
                    Name="GetListItems" />

   <SoapAction>
      http://schemas.microsoft.com/sharepoint/soap/GetListItems
   </SoapAction>
</Query>

The difference from the books online is the <Method> node which seems trigger something in RS to handle the issue. One other note is that even with the Method node, SSRS is still picky about the parameters so I have pretty much gotten by using only the essential parameters. I haven’t really built upon this example too much further but feel free to leave a comment if you have.

The Recipe
The following instructions assume an existing report but they should still work just fine using the add report Wizard.

  1. Add a new Data Source
  2. Set the Command Type to Text
  3. Set the Query string using the syntax above
    Example:
    <Query>
    <Method Namespace="http://schemas.microsoft.com/sharepoint/soap/&quot;
    Name="GetListItems" />

    <SoapAction>
    http://schemas.microsoft.com/sharepoint/soap/GetListItems
    </SoapAction>
    </Query>
  4. Set the parameters in the Parameters tab
    • Use the param name from the WSDL
      Example: listName
    • Use a list name for the value
      Example: Events
  5. Close the dialogs and run the report

You should now have at least some data coming back. If you have any specific problems and/or fixes please feel free to post a comment.

InfoPath stops loading drop-down values from data connection

A very strange problem indeed …
 
We have an InfoPath (SP1) form the has a handful of drop-down lists each of which gets its values from a secondary data source.  This data source, in turn, gets its data from a web service.  Very straightforward and very "working."  That is, until it randomly stopped working.
 
We could not figure out why it stopped as we hadn’t made any major changes.  Although, we did frequently update the data connection between dev and deployment servers so we thought the constant back-and-forth somehow screwed up the various XSDs and XSLs that are in the InfoPath solution.  Given our assumption, we deleted the data connection and replaced it (no dice) then deleted the drop-downs and the data connections and still no luck.  As a last ditch effort we reverted back to an older version of most of the files, deleted all binaries, cleared all cahces.  Same behavior! What the ….
 
After many many many hours of trying different combinations of everything we could think of … I decided that we needed to re-create the view.  However, there are well over one hundred fields on this form so doing this from scratch was simply not an option.  So, on a whim, I created a new view, cut/pasted the default view’s content to the new view, deleted the old view and made sure the new view was set as the default view.
 
Now everything works fine. Go figure!

Events not firing for controls in the HeaderTemplate of a Repeater

Problem
At a client’s site, we were making extensive use of Repeater controls to render data piped to it via a custom entity and collection.  In addition, we wanted to implement sorting in the repeater using LinkButtons which were rendered in the HeaderTemplate of the Repeater.  So for so good … seems like a pretty reasonable request and it works. 
 
In addition to this, we also hosted these Repeaters (amongst other UI elements) in a UserControl so that we could take advantage of the WYSIWYG design features of Visual Studio.Net.  These UserControls, in turn, were to be re-used in several aspects: hosted on ASP.Net web pages, loaded dynamically into server controls, and loaded dynamically into SharePoint WebParts.  The last was the most important as prior to ASP.Net 2.0 there are no easy WYSIWYG methods for creating WebParts so we decided to host UserControls inside WebParts.
 
At this point, the UserControls worked just fine when hosted on an ASP.Net web page leading us believe everything was ok.  We dropped the user controls onto the test web page and used the Page_Load event to pass data into the control to be rendered.  The LinkButtons that were in the header of the Repeaters re-sorted the data and everything looked great.
 
Next came the WebParts
At this point we created WebParts that were designed to host the UserControls and pass along any personalization and configuration properties from SharePoint’s Storage to the UserControl.  Again, everything appeared to be working great with one exception: The LinkButtons were no longer sorting!  I figured it had something to do with the fact that I was lazy and did all of my work in the RenderWebPart method (no need to lecture me; I have learned my lesson).  I moved the call to Page.LoadControl to the CreateChildControls() method where it should have been the entire time.  This would assure that the UserControls were created and added to the Page’s collection in time for the events to fire.  Almost there….
 
Still … the events did not fire but I still had a little bit of laziness left in me.  My thoughts went back to when I gave SharePoint WebPart development training.  In my own words were: "You should create the controls in CreateChildControls, load them in the Load event of that control, and ONLY render them in RenderWebParts."  Of course, there is a reason for this which I now realize. 
 
In a Repeater control, the HeaderTemplate (and FooterTemplate) is not created until the DataBind event is called and, thus, any controls in the template will not exist until that happens.  In my laziness I had not moved the actual loading of the data in the UserControl out of the RenderWebPart method so while the control itself was getting added to the controls collection at the correct time, the LinkButtons did not exist.  Following my own advice I moved the loading code into the UserControl’s Load event (on the web part) and now everything works as advertised.
 
The Moral
Having passed my ASP.Net MCP … I should have known better.  Having uttered the words in training that would have prevented this from being a problem in the first place … I should have known better.  Being lazy at the wrong time … priceless.

Oracle 9i Client and System.Data.OracleClient

If you haven’t yet upgraded to a newer Oracle client (e.g. 9.2) or you
are having problems with your current Oracle client (9i or higher) then
you will need to take a few steps to make your client work as you might
expect.  There are two main considerations:

  • TNSNAMES.ORA must be local
  • Permissions must be reset on your client directory

tnsnames.ora
Typically, companies will centralize the tnsnames.ora files (used for
resolving Oracle service names) but putting it on a fileserver and
pointing to it in the registry.  This works just fine for Oracle’s
toolset and many other client programs with the exception of the
System.Data.OracleClient ADO.Net provider.  The provider, for some
reason, expects this file to be installed locally (example:
c:oracleora92…tnsnames.ora).  Installing (and perhaps
mirroring from a network share) locally will take care of the first
requirement.

Permissions

For some reason, the permissions for the "Authenticated Users" user is
not fully propagated throughout the Oracle client install.  The
fix for this is straightforward as well:

  1. Open Explorer to your client install directory (c:oracleora92)
  2. Right-click ora92 and select propertied
  3. Select the "Security" tab
  4. Select the "Authenticated Users" entry
  5. Uncheck the "Read and Execute" attribute
  6. Click Apply
  7. Re-check the "Read and Execute" attribute
  8. Click Ok
  9. Reset IIS

At this point the Oracle provider should work!

Proper source code management of your Visual Studio 2003 solutions

Source Control, and thus products like Visual Source Safe or CVS, is obviously an important part of your software development life cycle but can also be a source of frustration (especially for ASP.Net web projects).

It is important to have a standard, repeatable method for any process in your SDLC including your project structure and source code management. Visual Studio makes this even more important for ASP.Net projects given it’s natural tendency to put all of your web projects under wwwroot. While this is a perfectly acceptable solution for some teams, many prefer to have their entire project under one folder structure. Reasons for this range from obsessiveness to easy of backup to convenience. Below is a good (mission tested) method for source code management in Visual Studio.

Step 1: Decide on your folder structure in advance
Through experience, anecdotal and empirical evidence, common sense and (of course) trial and failure many people in the industry have come to agree that to following folder structure just makes sense.

…SystemNameSolutionNameProjectName

System Name represents an overall name for your system (like EcommercePortal) and allows you to group not only more than one Visual Studio.Net solution but other components of your project as well (documentation, diagrams, etc.). Solution Name corresponds directly with the name of your VS.Net solution. If the folder does not represent a VS.Net solution then common sense prevails on your naming and hierarchy from this point on. Finally, Project Name is simply the name of your VS.Net project where the solution folder can have one or more projects in this branch.

The root location of this structure does not initially matter (e.g. on team member can use d:SystemName… while another uses his My Documents folder); However there are certain cases where the full physical path makes a difference. InfoPath projects, for example, become much more easily managed if all team members are using the exact same physical path.

Step 2: For ASP.Net web projects, pre-create your folder structure
At this point, if your solution is going to contain one or more ASP.Net web projects you should create the folder structure in advance in preparation for the next step. The following would be an example of a full folder structure for an Ecommerce web front-end:


c:ProjectsEcommercePortalEcommerceSolutionEcommerceWeb

Please note: In Visual Studio.Net 2003, the folder and project name of your ASP.Net web project must match the name of the web (virtual directory) under IIS. This is a good time to choose a logical name for your web application before you have added any value.

Step 3: For ASP.Net web projects, create your virtual directory
Normally, VS.Net would create all ASP.Net web projects (new or from Source Safe) under the default website’s directory (usually c:inetpubwwwroot). However, it is often desired to keep all of your project files in a single folder structure. To coerce VS.Net to create your web application within this folder structure you simply need to setup a virtual directory with the same name as your web project and folder. In above example, you would create a virtual directory named EcommerceWeb pointing to that directory.

The easiest way to create a virtual directory is to do the following:

  • Locate the physical folder user Explorer
  • Right-click the folder name (EcommerceWeb) and select Properties
  • Click the Web Sharing tab
  • Click Share this folder and accept the default settings
  • Click OK until all property dialogs are close

Step 4: Create your solution

At this point, you can finally begin creating your Visual Studio.Net solution that will contain your projects. Using Visual Studio, create a new Blank Solution, name it appropriately, and save it in the directory you created above. Continuing this example, your solution file should be created as follows:

c:ProjectsEcommercePortalEcommerceSolutionEcommerceSolution.sln

Step 5: Add the empty solution to source control

Now that you have your folder structure and blank solution you can start putting it into your source control system. This will pre-create the structure you have so far and make the rest of the processes a little bit simpler. The following list demonstrates this using Visual Source Safe:

  • Right-click the solution in your Solution Explorer and select "Add Solution to Source Control …"
  • Assuming no previous structure exists under VSS:
    • Single-click the root ($/)
    • Enter your system name (Ecommerce) into the text box and click create
    • Single-click the newly created project (Ecommerce) and click OK
  • If your system/project already exists under source control, simply select the system name and click OK

Note: VS.Net will automatically create a sub-folder/project for your solution directory (EcommerceSolution) so there is no need to create or select this in your source control dialog.

Step 6: Create your project(s)

You can now add projects to the solution as you normally would with one note: For ASP.Net projects make sure that you name your project the same as the virtual directory you created above. If you are prompted, check out your solution file.

Step 7: Bind your project to source control

With the exception of ASP.Net projects, your solutions will be properly created under the solution directory when you check them into source control. However, ASP.Net projects will not be created where you anticipate. The following instructions will re-bind your ASP.Net project under the correct hierarchy:

  • Open your source control client
  • Under the solution folder/project (EcommerceSolution) create a new folder/project with the same name as your ASP.Net project (EcommerceWeb)
  • Back in VS.Net
  • Click File->Source Control->Change Source Control
  • Click on the link for your web project (EcommerceWeb)
  • Click the Bind button
  • Select the folder/project you just created (EcommerceWeb)
  • Click Ok Twice
  • If prompted, select "Continue with these bindings"
  • If prompted, allow VS.Net to check-in any files
  • In your Solution Explorer, check-in the entire solution

Final Step: Getting the source tree from source control

You now have your entire system, solution, and projects checked into your source control system in a manageable hierarcy. However, there is still one more precaution the rest of your team needs to take before they begin working with this system: they need to get the entire source tree back out of source control without undoing any of the above steps.

The safest and cleanest way of getting the source tree is to follow Steps 2-3 above, then use Visual Studio.Net’s "Open from Source Control" wizard (under File->Source Control). You will need to navigate down to folder/project where your solution is under source control and make sure your local path in the dialog matches what you created in Step 2.

Another method is to use your source control client to get a local copy of the source tree (outside of VS.Net) and then create your Virtual Directories (as in Step 3) for your web projects BEFORE you open the solution in VS.Net

Checking in BizTalk file before editing can corrupt the file

We’ve all been there…
When you are working with a team of developers (whether two or ten),
who are collaborating on a project in Visual Studio.Net, there
certainly is the chance that you will need to add a new file to the
solution.  Of course, to do this you have to check out the project
file locking it for yourself.

Play Nice!
The courteous thing to do (karma, right?) is to add your file and
immediately check in the new project file with your newly added file
(as long as it doesn’t break the build 🙂 ).  Try doing this in
BizTalk sometime (if you already haven’t) and watch the quick
destruction of your file.  Once you start editing that file again
and check it back in you get a nice little warning about the encoding
type changing.  Visual Source Safe does not handle this very
gracefully; Visual Source Safe does not handle this at all.  You
will be fooled into thinking your file is safe because you are working
with the version on your local disk but the next time one of your team
members gets the latest version of your project the file will be toast.

What the …?
The issue here is that when you create new files in VS.net it likes to
create them as UTF-8 encoded files.  Seems like a good idea; a
nice standard encoding type.  BizTalk, however, has to be
different and save everything as UTF-16.  Once again, another
nice, standard format.  However, visual source safe is completely
oblivious to the change in encoding types an will gladly assume that
your are still managing a UTF-8 encoded file.

The Moral
You can still be a gracious team member and have a quick
turn-around on adding new files to the project but just give those
files a little edit first before you check everything in.