I recently re-looked at The World is Flat by Thomas Freidman and couldn’t believe it did not mention LinkedIn or Twitter.  It reminded me of the old days that I will characterize as before Moore’s Law and when Bell Labs still existed.  In those days we talked about strategic planning in three ways:

·         The inertial future- It might have been five years, but it consisted of technology, products and plans that you had in the pipeline.  Regardless of what assumptions changed, you were largely constrained by the capacity, tools, channels and products  that were in place.  The rocket had left the pad.

·         The planning future- This was the time frame where you had some flexibility to make choices.  You could choose a platform- analog/digital, front wheel/rear wheel drive, TDMA/GSM, etc.

·         The unknown future- This period was where new technology, market trends, and cost structures were still unknown.  Usually it was not a horrendous problem because the options became clearer before you had to have a plan. 

Now, every time one of our team goes to a conference- product life cycles, technology curves and planning horizons all compress.

I think we now operate where the product life cycle is driven by the inertial future of a year, but the underlying technology is somewhere in the unknown future just six months ahead.  Is that a bad thing?  Not if your nimble, retool your skills and step to the side of the customer in understanding what drives their market.

Scenario: Suppose that you have a SharePoint site with hundreds of ReportViewer 2005 WebParts deployed.  You need to upgrade to Reporting Services 2008 SP1 for one reason or another (all hail the Tablix!).  You upgrade to 2008 and all of the ReportViewer 2005 Web Parts in your site are broken by the update. 

 

Searching the in Microsoft support forums, at least in the beta 2 version of 2008, web parts would need to be updated manually to the new version according to the respondents.  But I think I've found a better way.

 

Instead, for a work-around, I would recommend  adding a line to each farm web.config redirecting the old Web Part assembly from the old version to the new version of the assembly.  It is a lot breezier to make a change in one place than to programmatically fix the web parts in hundreds of places.  (Caveat programmer: I haven't read anything to warrant that the new version of the ReportViewer 2008 is completely backwards compatible with the ReportViewer 2005 web part.  Other than in our farm, we've gotten it to work. ) 

For instance, within the SharePoint web.config dependent assemblies section add something like the following:

 

<dependentAssembly>
<assemblyIdentity name="Microsoft.ReportingServices.SharePoint.UI.WebParts" 

publicKeyToken="89845dcd8080cc91" culture="neutral" />
<bindingRedirect oldVersion="9.0.242.0" newVersion="10.0.0.0" />
</dependentAssembly>

The newVersion attribute and oldVersion attribute should, of course, be set to the value of your specific new version of Microsoft.ReportingServices.SharePoint.UI.WebParts and the old version respectively.  

Just how beta is Beta 1?  Although my install on a VM running Windows 7 Beta 2 x64 went smoothly, the first time I opened VS 2010 it crashed my VM running on Fusion.  Ctrl+Alt+Delete didn't have any effect.  Fusion was stumped in restarting, shutting down, or suspending the image, but finally restarted the image after four or five minutes.  

I added more juice to the VM.  Another virtual processor.  Rebooted.  Another crash.  

Ah well, I'll have to find the time to futz or figure it out.

In the meantime, the beta 1 documentation is up on MSDN, and there are a few new features I haven't seen mentioned else where before with .NET.

What's new in .NET 4?

Reading “The Pragmatic Programmer”, one concept that it mentioned was native to some programming languages, but up to this point foreign to .NET is code contracts.   I imagine someone must have implemented code contracts before using Attribute Classes in a non-Microsoft library, but speaking out-of-the-box, the code contracts were implicit:  unit tests or thrown exceptions.    

“Code contracts let you specify contractual information that is not represented by a method's or type's signature alone. The new System.Diagnostics.Contracts namespace contains classes that provide a language-neutral way to express coding assumptions in the form of pre-conditions, post-conditions, and object invariants. The contracts improve testing with run-time checking, enable static contract verification, and documentation generation.
The applicable scenarios include the following:
Perform static bug finding, which enables some bugs to be found without executing the code.
Create guidance for automated testing tools to enhance test coverage.”

I  am interested to see if this results in the creation of more dependable code and/or less test writing tedium.  I am also interested if testing code coverage can be made more consistent through test code generation, e.g. instead of remembering to test border conditions, null conditions, etc. the tests are a mirror to the contract.  

 

---

Update:5/25/09 - After installing VS2010 Professional on Windows 7 RC (e.g. following the directions in the System Requirements), I have been able to open the new IDE and explore.

As I was reviewing our SharePoint customer experiences over the last year, the three legged stool came to mind.  There is nothing more stable than a stool when you have three legs, remember your geometry, three points make a plane; and without three you can’t stand it up.  Anyway, our experience has shown that every successful SharePoint engagement requires three skill areas:

 

Infrastructure Design/Deployment/Refinement              

• Design and Plan SharePoint deployment
• Effectively deploy SharePoint environment
• Integrate third-party web parts/applications as necessary, work flow, etc.

 

Architecture/Information Taxonomy                                     

• Establish Site Navigation/Search Strategy (Contextually Aware)
• Establish Business Processes, Document/Form Centric workflows
• Design Information Management (Documents, Web Content, External Data)
• Governance Model

 

Software Development                               

• Construct Site Definition/Feature Stapling
• Build custom web parts, page layouts, workflows, content types
• Create custom back-office data access, BDC’s   

 

We have found that in-house staff and many consulting companies have strong skills in one or maybe two of the disciplines, but seldom all three.  Successful implementations require all skills working in unison. 

Once upon a time, a code cobbler named Jack needed to share data from one piece of code to another piece of code.  In a hurry.  "I know, I'll shove it in ASP Session state."  Slowly, the session code grew longer, and the number of sessions variables increased beyond measure.   The code beanstalk snaked through the code and across modules up into the cloud.  The number of possible system states grew past the number of atoms in the universe, and with it the number of possible error states. 

All of a sudden an angry giant appeared and shouted, "fee-fi-fo-fum, foobar, I smell a wicked code smell."    And so Jack the code cobbler had to spend time weeding the beanstalk instead planting something useful.   The End.  

So there's my next book proposal: "Technically-Correct Fairy Tales."  What other tales can I regale?  I'm open to suggestions.

I am pretty sure that the three little pigs with their various architectures of straw, wood, and bricks is applicable to code architecture.  The wolf is business change.   The straw is the short cuts that over the application lifecycle become long cuts.     The brick is lean programming methods. Pragmatic methods.  We have to use the brick until some space-age, huff-and-puff, hurricane-proof material replaces it.

Maybe I shouldn't use the anodyne, censored versions of the fairy tales. The brothers Grimm original versions may prove more suitable.  Beware the marketing-based, candy houses!   Beware the GOTO breadcrumbs!  Yeah, not too interesting, I guess I won't make it as a fabulist.

I've started watching fora.tv.   I like the following two segments because they dovetail with how I answered a question on one of my Linked-In groups in regards to if there is a strategic advantage for .NET developers  that Microsoft will not be bought out tomorrow (in response to the news of Oracle's acquisition of Sun).   The avenues for computing are increasingly more than desktop and server.  And as the generation shifts and the boomers retire, Microsoft will have to adapt if it doesn't want to see its core business atrophy and wants to take advantage of the new opportunities (as Ray Ozzie has acknowledged with the Software + Services strategy). 

 

Microsoft Word can become a Word Star.  More realistically it might have to be hugely discounted.  It's not impossible.  So for any strategic advantage for .NET developers, Microsoft's dominance exists squarely in the short term.  It's also too early to tell all of the implications for Java - the change in ownership may revitalize it for all we know. 

 

 

The RDBMS is most often our data store of choice.  However, how do applications with millions of users scale-up?   

 

If one excuses the overblown title, "Is the Relational Database Doomed?" provides a good, high level overview of the constrast between relation database systems and current cloud store technologies used and now being opened to the wider developer community by companies such as Amazon and Google. 

 

One can say the grid-based storage solutions must have some level of maturity by the very fact that systems like Google's don't collapse under the weight of the user volume.  However, as the article make clear, this doesn't mean there aren't trade-offs with using current grid-based storage technology versus a traditional RDBMS.  These trade-offs force differences in code architecture.   

 

That said, the newly available cloud storage technologies are worth watching closely - for many applications the economics of the situation leave little doubt that increasingly cloud storage will be the preferred course for non-mission critical data. 

Recently, we at Aspenware converted some of our coding guidelines and standards to the wiki format. 

I would hardily encourage any software development shop to consider implementing a Developer wiki to create a repository of best practices and internal documentation.  What excuse could you possibly have not to?  Wikipedia-class wiki software can be had for free at mediawiki.

If I were to ask the Feature Fairy to grant one wish for the next version of  Visual Studio Team Foundation Server 2010, it would be for wikis to be integrated into Team Project portals right out of the project template.   

Scratch that. Right now SharePoint 2007 has a wiki library feature that could be deployed.  I just ask the Feature Fairy to provide a decent, usable wiki for Team Project portal integration.

No doubt the SharePoint elves are already hard at work...

Apple's OS X and iPhone language du jour Objective-C contains both archaisms and a number of excellent ideas.  One of the quite obvious archaisms for beginning Objective-C programmers is that there is no .NET or Java equivalent to namespaces.   (On the bright side, rather than navigating namespaces to find needed bits of functionality, this forces clearer documentation in XCode of the Cocoa framework.)   The hack that most use is to append three characters in front of class names to prevent name collisions. 

Until now many of the better ideas have not been integrated into the .NET Framework.  One superb facet of Objective-C is that while supporting plain vanilla C function calls, for objects methods are called with a syntax that allows clear definition of the method parameters within the method name.  Each parameter is prefixed with a token that can be used to define the nature of the arguments, hence leading to a more readable API. 

In Objective-C, if I have a class called Rectangle, and instantiate an instance called MyRectangle, I could create a class definition that allows me to modify the dimensions with the following syntax:

[MyRectangle alterDimensionsWithHeight:35 Width:35];

The method signature in the object for a non-static method would be:

-void alterDimensionsWithHeight:(NSInteger) height Width:(NSInteger)width;  

 Named arguments in .NET 4.0 brings C# closer to this ideal, as this MSDN blog details, along with numerous additions to C#.

 It will be possible to invoke a method now with the following syntax:

MyRectange.alterDimensions(height:35, width: 35); 

This may not make a difference for methods with 2 parameters as in this example, but for methods with 10 or 15 this will make it far easier to read.

Once this feature is around, it should then be possible to force a compiler error if a programmer does not include the named argument parameters. 

One of the most useful SharePoint and SQL Server features is Reporting Services SharePoint integration mode.  With it reports become accessible from within SharePoint portals and RDL reports and associated datasources are stored within SharePoint libraries.

In using this feature, I have found a short-cut for populating my reports that contain a common blueprint and structure: CodeSmith.

CodeSmith is a .NET template based code generator.  Using CodeSmith you can code a template to generate code such as T-SQL or in the case of Reporting Services, RDL Xml documents.

Take one scenario, let's say you wish to generate Reporting Services reports exposing the KPIs of multiple company departments over time.  If you have those KPIs ("Key Performance Indicators") exposed via a single view, you can quite easily in CodeSmith create an individual Report focusing exclusively on each KPI.

Step 1: Create a View containing all Report KPIs to be shown in a similar report.

e.g.

CREATE VIEW [COMPANY KPI]

AS SELECT CompanyDepartment, ReportPeriod,  [KPI #1], [KPI #2], [KPI #3],...[KPI #N]

FROM KPI INNER JOIN DEPARTMENTS ON KPI.CompanyDeptID = DEPARTMENTS.CompanyDeptID

Step 2: Create Your Template RDL Report within Visual Studio 2005 or 2008.

If your Reporting Services target is SQL Server 2005, using VS 2005.  If it is SQL Server 2008, use VS 2008.  Use the Reporting Services wizard to create a matrix report using the first KPI, e.g. [KPI #1].  

Step 3: Create and Run a CodeSmith project in CodeSmith Studio. 

In the ReportSubTemplate.zip are two example .cst (CodeSmith template) files.  The ReportsGenerator.cst is the controller template, which loads an instance of each ReportSubTemplate.cst that contains the actual RDL xml copied from step 2, and then renders and saves each generated Report to text files for each KPI within the view.  The output is one KPI#N.rdl file for each KPI column in the view which can then be added to a Report project for deployment.  CodeSmith has a library to read database meta-data that you can operate on to loop through Table or View columns. 

In the properties of ReportsGenerator, is merely necessary to select the SourceView from a CodeSmith data source and then build and run the template.  (After changing path properties to their respective local values.)

In manipulating meta-data, if your database columns follow naming conventions you can more easily format the output reports based on those naming conventions.  E.g. to apply the Format P for percentage ,or C for currency, you could introspect if the column type is money, or look for the token "Percentage" within the column name and then create a CodeSmith hosted method which will output that result based on the naming convention. 

Aspenware is a sponsor of Ride the Rockies.  An early version of our newest application displays the mapping of the route.  Please check it out.  We will be rolling out a greatly expanded version of the application letting you post, comment on and share the best rides you have taken anywhere in the world, whether it be road or trail.  We also will be in need of a team Sherpa for RTR to drive a pickup with our gear and set up/take down our tents, and basically hang out with us the rest of the time.

If you are looking for the technical jargon that would be Daniel or one of our other bit wizards.  I'm a market guy and this is more about what I see out there.  The light at the other end of the tunnel may be the economy turning up or it may be the reporting requirements train coming toward you.  With the stimulus plan underway through the American Recovery and Reinvestment Act of 2009 (ARRA) we have just begun to see inquiries regarding reporting requirements.  While this started with governmental and quasi-governmental agencies, it is now trickling down to prime and subcontractors.  Areas where we see it already are in infrastructure work for things such as environmental clean-up and revamp of the health care infrastructure.  The latter covers a whole range of things from sharing of information through Electronic Medical Records and Personal Health Care Records to tracking of Medicaid eligibility.  In some cases customers already have the tools in place to handle such needs, but perhaps not properly configured.  In bidding for contracts it is important to have a robust, auditable system and flexible system that can address the evolving requirements as the money flows through the pipeline.   The rules aren’t completed so your system better flexible to address because we know it will get curiouser and curiouser.  Soon to follow a business requirements document for lending institutions that have ARRA money.

Now this is something I'm going to have to get my hands on a VS 2010 CTP or beta when it's available, but if C#3.0 introduced implicit static typing in variable declarations, C#4.0 appears to introduce what I can best describe without any exactitude, as explicit dynamic typing.  A variable can be declared as dynamic type with that very keyword, which tells the compiler that any calls to the object and the type will be resolved at runtime rather than compile time.

After reading two or three posts about the new C#4.0 features, I can't get my head completely around every feature, so the cure to me appears to create a VS2010 virtual machine and to experiment.  The most readable explanation I've gotten of the new features in C# is from "New Features in C# 4.0" on the C# 4.0 October 2008 CTP site. 

I imagine that like reflection, there is a performance penalty in using dynamic binding rather than static, but that the flexibility might come in handy in a minority of situations - one of which the article mentions is COM interop.  I haven't seen anything in C#4.0 that seems as dramatic as C# 3.0 and 2.0. For VS 2010, I am anticipating useable SharePoint development tools, an expanded Base Class Library with frameworks like MVC, more than changes to the core language.  For day to day work with web development and Silverlight, I haven't seen much at the syntactical level that is going to be as common place as generics in 2.0 or extension methods and lambda expressions in 3.0.

One that may be, but is unrelated to dynamic binding, is implicitly casting one generic array or data structure like a List to another without writing code to cast each member object of the data structure to the underlying type.

i.e. from the examples given, I understand that one can in C# 4.0 perform the following generics operation without compiler-kvetching:

var stringList = new List<string>();

//...Add strings to the list.

List<object> objectList = null;

objectList = stringList; // formerly a compiler conniption fit.

I'm stuck in the comparison of a dynamic language like Objective-C with a static focused one like C#.   I wonder how many object design patterns could be borrowed from Objective-C or other languages for aspects like plugins or provider models.  I guess it is a matter of using it and discovering the limitations and how much the benefit weighs against draw backs like possibily slower debugging, when errors are discovered at runtime rather than compile time.  

I think I  will ask StackOverflow the question of what the benefits are of a hybrid model of static and dynamic typing in the next version of C#.  How programmers believe it will change or not change C# programming.  Once I do I'll post the link here if there's not already a question about it.

Update: here's a question on Stack Overflow which has pros and cons for the introduction of dynamic to the C# language: http://stackoverflow.com/questions/244302/what-do-you-think-of-the-new-c-4-0-dynamic-keyword.

I ran into the situation where users of an application newly in my care started missing records displayed in the user interface.  They had input the records, but they were no where to be seen. Usually if that escaped QA, that would mean an error introduced in code in the last release, or a change in the database, or some sort of data change triggered a latent application error state not covered by unit or integration testing. I had my usual suspects, so I went down the list.

Upon inspection, the code hadn't been updated for three weeks.  The problems were noticed only in recent days.

A database comparison revealed no major differences in the schema areas populating the user interface.  They hadn't been changed since the release either. 

Running a mirror of the production database locally produced normal application behavior.  More bafflingly, running the equivalent of the Stored Procedure queries on the production SQL server produced the expected data set.  Running the Stored Proc did not.

So something was in an abnormal state...but where?     It couldn't be a network issue, other data populated fine.  It was time to dig into the Stored Procs.

SELECT * FROM SOMETABLE WITH(NOLOCK)   WHERE X = @Something  /* Simplified Example */

The WITH(NOLOCK)!  It was telling the SQL database to retrieve the data regardless of write locks.  But if the server utilization and queuing increased, there was the possibility that a user might add a new record, and in code right then and there retrieve the updated dataset of records, and because the new record may not have been committed, not retrieve the newly created record.  Since I found the WITH(NOLOCK) in a SQL View, and the view was called from a stored proc, SQL caching of the input and result sets appear to have prevented retrieval of the new records in subsequent execution of the stored proc.  At least, without trying to recreate the situation and looking at the SQL Logs and Execution Plans, that's what I surmise.

WITH(NOLOCK) can keister-bite you right out of the RDBMS blue. Especially if the table data is in a constant state of change. The more transactions per minute, the dirtier the reads. 

In googling the topic, I came across a bit of twitter-wisdom...."WITH(NOLOCK) is a code smell."

Use sparingly. 

WF is certainly a disappointment in its present form. 

On the surface, you could get excited that this would simplify a great many programming tasks, but the simplicity was deceptive.  For SharePoint programming in particular, something as fundamental as having a Delay Activity ("Wait 2 hours than move on", etc.) doesn't even work correctly unless as of today's date you have hotfixes post-SP1 that may break other SharePoint functionality. 

It is to early to get hopes to high, but in the .NET 4.0 release, there may be an answer.   

VSLive!: Expert Describes Windows Workflow 4.0 as a Vast Improvement Over Prior Versions

It should be interesting to see how this changes the workflow ecosystem, where often the best bet is to use third-party software like K2's blackpearl to obtain a usable Workflow host. 

I was hoping I could find an example of Powershell to activate features in the case where there are hundreds of subsites.

Luckily, there were already examples out there: http://bable.cybermarshall.com/2009/01/17/using-powershell-to-activate-a-feature-across-all-sharepoint-2007wss-30-sites-and-subsites/

In general, I am impressed with Powershell's regularity as a scripting language versus the two-fingered mass-irregularity that you find in Unix shells.  It's also cool that you can use well-known Unix shell commands so you don't have to sacrifice concision for regularity if you don't need or want to.  One tool I've found to make saving scripts and starting out in Powershell a snap is Power GUI.

A common scenario in SharePoint workflow development is the need to upgrade a running workflow.  But how do you upgrade a running workflow without causing the dreaded "Task is locked by workflow" error?  (If you get this error, the only surefire resolution for the workflow associated with the locked task is creating a new workflow instance with the new workflow version, which may or may not work depending on your situation.)

To avoid breaking running workflow instances instantiated from the older version of your workflow, follow the following rules of thumb:

1) Always explicitly version the Assembly containing your workflow.

With any change, go to the Workflow Project Properties > "Application" tab > and then click on "Assembly Information." 

 Increment both the "Assembly Version"  and "File Version" in tandem.

Open the associated workflow.xml in the project and increment the assembly version in the CodeBesideAssembly attribute in your Workflow element.  Because you have to manually change the CodeBesideAssembly, I recommend not using the auto-incrementing * version asterisk in the Assembly Version and File Version for SharePoint workflows unless you do some scripting. 

2) Keep a folder with each legacy version of your workflow assembly.

If your SharePoint installation process deletes the older workflow assembly from the Global Assembly Cache, re-add the version bound to the previously running workflow via the .NET Framework 2.0 Configuration Tool or via commandline.  (E..g if upgrading to 1.0.0.20,  add the previous version 1.0.0.19 to the GAC after installing the new version.) This is another step that can be worth scripting.  You can then browse all assembly versions of your workflow using the "View List of Assemblies in the Assembly Cache. 

3) Version the Workflow SharePoint Feature 

I haven't tested whether this is absolutely necessary, however, like lucky socks, I don't risk not incrementing the SharePoint feature version:

In the feature.xml, the feature element, increment the Version attribute: e.g. Version="12.0.0.5". 

4) Restart IIS or at least the relevant App Pools. 

Again lucky socks, or just the need to refresh SharePoint caching.

5) Make sure from the Remove Workflow admin screen of your list or library (Workflow Settings > Remove Workflows), that only your new version can "allow new instances," and that the older instances are set to "no new instances." 

 If you create a test item, you could start an older workflow before any updates that could continue to run after the updates to confirm that the older running workflow instances don't error out unexpectedly with actions like task modification. 

In the past, to integrate with QuickBooks financials, it was necessary to code a Windows Service or Windows Form application to access and modify accounting information. 

Thankfully, this is no longer the case.  There are other options.

One of which is using QuickBooks Web Connector in combination with a web service with a compatible interface.  In Web Connector, Intuit has provided a generic client to handle message exchange.   One limitation to this approach is that QuickBooks Web Connector has to poll your web service on a scheduled basis, so that it is not suitable for real-time messaging (If this is necessary or there is enough message volume, it might be a better idea to look at a more scalable accounting system or QuickBooks Enterprise anyways). However, for instances where a multi-second or multi-minute delay is permissible, it works fine. 

The basic operation is that on a scheduled basis QuickBooks Web Connector contacts your web service, goes through authentication and other plumbing steps, and then runs a message loop where XML documents are exchanged as request/response pairs. 

QB SDK 7.0 offers an example of a compatible web service, but the .NET example web service ("WCWebService") leaves a bit to be desired for a QuickBooks novice.

Namely, it constructs the example XML messages using XmlDocument-esque code rather than demonstrating how to use the QB SDK 7.0 object model in order to save time and ensure properly formulated XML messages.  I wouldn't recommend implementing your Web Service without using the Object Model. 

Creating Request XML from a Request Object:

QBSessionManager

_sessionManager = new QBSessionManager();

IMsgSetRequest invoiceSetRequest = _sessionManager.CreateMsgSetRequest(QBSettings.QBEdition, QBSettings.MajorVersion, QBSettings.MinorVersion);

IInvoiceAdd addInvoice = invoiceSetRequest.AppendInvoiceAddRq();

//Assign the invoice to a customer. Add line items, set values for the Invoice in your code here, etc.

//Call ToXMLString() to get the message you wish to return from the

//sendRequestXML Service operation in your Web Connector compatible web service.

string xmlToSendOver=invoiceSetRequest.ToXMLString();

Parsing Response XML into an Response Object:

IMsgSetResponse

msgResponse=_sessionManager.ToMsgSetResponse(Response,QBSettings.QBEdition,QBSettings.MajorVersion,QBSettings.MinorVersion);

if (msgResponse.ResponseList.Count > 0){

IResponse response = msgResponse.ResponseList.GetAt(0);

if (response.StatusCode == 0) {if (response.Detail is IInvoiceRet){

IInvoiceRet invoiceReceipt = (IInvoiceRet)response.Detail;

//Example of getting the Transaction Id in order to query QuickBooks later about this Invoice's payment status, etc.  

TrxId = invoiceReceipt.TxnID.GetValue();}

}else{

  //Exception

}

...

Things to note, you can anticipate the type of response object from the message sent.  I used a Stack primarily as the data structure to store the wrapper objects controlling the QuickBooks Object Model code.   The SDK example uses a plain ole' .NET V1.0 List. 

This comes under the category of nuisances, but if you modify your WCF web service contract, and then likewise need to modify a WCF Send Activity that references this contract in your SharePoint workflow, it helps to take the simple step of deleting or uninstalling any previous versions of your code from the GAC to get the Send Activity to refresh.   It may also be necessary to close and reopen your SharePoint workflow solution.

Even if you have set your SharePoint workflow and Send Activity to reference a seperate project library, it will continue to reference the previous GAC version of the library with a now invalid WCF contract unless you delete the GAC version, or explicitly version your code.  (Which is why I won't go so far as to call it a bug.)

One of the convenience features of the NetTiers Data Layer generator is the ability to generate enums from Lookup tables. 

However, to successfully generate an enum from a Lookup table, you must have a primary key column and your varchar or nvarchar look-up column needs to have the uniqueness constraint.

I always forget the syntax to add the constraint, so here's the T-SQL for posterity and adding to Visual Studio snippets. 

ALTER TABLE TableName

ADD

CONSTRAINT Constraint_Name_UNIQUE UNIQUE (ColumnName