By Tim Wheeler on 6/25/2008

I have a .Net implementation of SRW/SRU if anyone is interested.  At some point I was looking at putting it online but just don't have the time at the moment.  If your looking at creating an SRW/U project in .net, leave a comment and I might be able to help.  For those that don't know about SRW its a way to query systems using standardised interfaces and metadata schemas.  So either XML Webservices or Xml from an HttpRequest.  View more info at www.loc.gov/z3950/agency/zing/srw.

Its also used in Federated Search, currently supported Te Ara www.teara.govt.nz.  Their SRU interface is here: www.teara.govt.nz/search/sru.axd.  A number of New Zealand and  Australian educational institues also support it for federated search.

By Tim Wheeler on 6/24/2008

I recently got to use the new database project in Visual Studio 2008 on a client project.  What a great improvement.  True it has a few quirks, but basically it removes a whole bunch of manual steps that we had to do in Visual Studio 2005.  I've found the DB project great in a team environment, when you want to work local and still source control your database scripts.  It has a cool feature called "Import Scripts", in which is parses the TSQL, breaks everything up into individual scripts, and places them in the appropriate folders.  It also gives you the ability to write your own scipts. To do that, you need to update Scripts/Post-Deployment (or Pre-Deployment)/Script.PostDeployment.sql.

Use the command ":r .\MyCustomScript.sql"

BTW, it generates an SQL script (in the SQL folder) as an output of the project.  It contains your entire database in one scipt.  However it is SQLDMO so you can't execute it in the management studio or query analyzer, you need to use the sqldmo command: 
osql -S localhost -d DatabaseName -i myscript.sql -E   (The parameters you need will be different depending on your script)
The database project allows you to create data generation plans, which is great for filling up the database after you create it.  

Here is my current approach to using database projects:

• Use it in a team environment to deploy and develop locally
• Deploy from Visual Studio (right click deploy) in development environments.
• Don't use VS to deploy to production or UAT, use the script.  (Which you will probably have to customise)
• Set the database to be re created on each deployment. 
• Have a post build script that will insert your reference or lookup data.
• Have a data generation plan to create you some base entity data to work with.
• Use the Import Scripts method carefully, (it depends how you generate your scipts)
• Version control with TFS/VSS or whatever.

Quirks:

• Current RTM version of VS 08 keeps the database project loaded entirely in memory.  Best bet is to keep this project unloaded (right click, unload from solution explorer) when you don't need it.
• It also seemed to have a bug where it didn't understand default values on the table scripts, and ended up erroring because it would try and apply constraints twice.  To fix this, look at how you are generating your table SQL, and update as needed.
• Data generation plan does not always work, keep trying.  Also, check your timeout settings etc on your connections.

By Tim Wheeler on 6/24/2008

I was trying to define labels for the content type in a document library.  I kept getting the error:

"The label reference, MetaDataFieldName, could not be found"

The column did exist but the error persisted.  So I turned off labels, set the auditing values and saved the policy.  I then went back into the policy and defined the labels and it worked.  Not sure why, but it seems you have to create and save the policy first, then return and add labels.

By Tim Wheeler on 6/23/2008

I have just uploaded the Code Artist for DotNetNuke module and added it to the Code Zone.  This module isn't available publicly yet but will hopefully be ready in a month.  The code zone is being constantly updated and contains reusable classes or examples.  Best of all its all Free Code, courtesy of www.purecoding.net.

 

By Tim Wheeler on 6/16/2008

Here is a common IIS error. 401.1 - Unauthorized: Access is denied due to invalid credentials.  Here is one possible resolution.

If an ASPNet site requires authenticated users, but your not using Integrated Windows Authentication then you might get a 401.1 error, with a login dialog that never accepts credentials no matter how many times you enter them. 

In IIS, edit the website or folder, click the Directory Security tab.  Make sure Integrated Windows Authentication is ON.  If you are still getting this error, it maybe that the account your app pool is running under does not have permission to files or registry keys.  Try turning on both Anonymous, and Integrated, or grant more permissions to your service account.  If your system impersonates, the requesting user will need permissions to whatever the site needs, like writing to the file system.  Not a very nice situation.  Its better to run under a service account and just impersonate when you need to.

Also try running:
Cd %systemroot%\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis –ga [domain]\ServiceAccount

 

By Tim Wheeler on 6/16/2008

If your Application Pool won't start in IIS 6, or has a little red x, make sure your account has correct local permissions.

When you specify a domain account to be your service account you need to add the account to:

Local Security Group IIS_WPG
Local Security Policy -> Local Policies -> User Rights Assignment -> Logon as a service
From a command prompt run:
Cd %systemroot%\Microsoft.NET\Framework\v2.0.50727
aspnet_regiis –ga [domain]\svcSQL_Reports
iisreset
Note: Reboot after you change the local security policy.  Obviously your service account requires correct ACL permissions on the file system, registry etc.

By Tim Wheeler on 6/6/2008

One problem with developing on Windows XP using IIS 5 is we don't have application pools.  So if your hosted system needs to access a domain resource you will get denied because its using the worker process ASPNet_WP.  Sure you could use some windows api calls and login as another user but then you have to manage credentials, and also its not needed for production as you can just set the app pool.  So, in Windows XP I want IIS 5 to run under a domain service account.  After a bit of trial and error here is the process I went through. 

1. Create a domain user account to be used as a Serivce Account.
2. Grant local permissions
3. Grant local security policy
4. Run aspnet command.
5. Update your Machine.Config
6. Reboot

Local permissions
You need to grant local ACL permissions for any file access.  If it writes log files you will need write permission.  If you log to the event log you will need write permission on the appropriate registry key.  Or just grant the service account local admin.  (Not defence in depth but ok for development)

Local policy
Administrative Tools -> Local Security Policy -> Local Policies -> User Rights Assignment
Add the service account to the following polices:

• Access this computer from the network
• Impersonate a client after authentication
• Logon as a service

IIS Permissions
Start -> Run:
C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -GA domain\accountname

Update your Machine.config
Run:
Notepad “C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\CONFIG\machine.config”
Search the "<processModel" element and Add or edit  to look like:

<processModel comImpersonationLevel="Impersonate" userName="domain\accountname" password="password"/>

Note: This is under the element <system.web>, and there should only be 1 processModel element.

After you update the Machine.config you need to reboot.

Note: When you are using WCF here are the command to get the user or the system Account:
Service Account = System.Security.Principal.WindowsIdentity.GetCurrent()
Calling User = System.ServiceModel.ServiceSecurityContext.Current.WindowsIdentity

By Tim Wheeler on 6/5/2008

After integrating the Enterprise Libraries Security block into my current project, I kept receiving an "Element Not Found" exception when the block was trying to access the AzMan store. 

Situation:
By default the Security Block will look for only AzMan Tasks, I was trying to authorize Operations.

Solution:
Prefix your operation name with an "O:", and BTW its case sensitive.  I must have missed that part in the help file. 

Actually I found the security block help dismal.  Didn't find anything on the net and came to the conclusion that not many people use it with AzMan.  However, after sorting that issue out and building a permission class with a nice enum, I've found that using AzMan and the security block is actually really good.  You can define the authorization to a very granular level.  Note: I've upload my AzManPermission.cs class to the Code Zone if anyone is interested.