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!

Advertisements

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.