"The form required to view this message cannot be displayed" error accessing Organizational Forms Library in Outlook 2003

I had a VB6 program running on a server using Outlook 2003 client to create appointments. The appointments used a custom Outlook form stored in the Organizational Forms Library. Suddenly the program started spitting out this error:

"The form required to view this message cannot be display. Contact your administrator."

If I used the Outlook Client (on the server) to try to design the form via Tools-Forms-Design Form-Organizational Forms Library-{shift}+Open then I got the following error message:

"The form you selected cannot be displayed. The form required to view this message cannot be display. Contact your administrator."

The solution was to clear the Outlook Forms cache. This can be done via:

1. Click on the "Tools" menu


2. Click on "Options"


3. Click on the "Other" tab


4. Click the "Advanced Options" button


5. Click the "Custom Forms" button


6. Click the "Manage Forms" button


7. Click the "Clear Cache" button


8. Close and OK through all Outlook Property/Option windows

Credit for these steps from http://www.experts-exchange.com/Software/Server_Software/Email_Servers/Exchange/Q_24342937.html

Compile All Invalid Oracle objects

If you add a column to a table that invalidates lots of packages, triggers, views etc then you'll need to compile all of these invalidated objects. And each of these objects might in turn invalidate more - so this can take a few cycles.





I use the SQL statement below to generate the COMPILE statements for all invalid objects. I then copy and paste the COMPILE statements into a SQL session and run them (compiling them). Then I run the code below again (and compile again...etc) until no more are found.

SELECT 'ALTER '
  ||decode(object_type,'PACKAGE BODY','PACKAGE', object_type)
  ||' '||object_name||' COMPILE'
  ||decode(object_type,'PACKAGE BODY',' BODY', '')||';'
FROM user_objects
WHERE status = 'INVALID' 
AND object_type <> 'SYNONYM'

The output from this (which I paste into a SQL window to run) will be something like:

ALTER TRIGGER CUST_AUI COMPILE;
ALTER PACKAGE CUST_PKG COMPILE;
ALTER PACKAGE CUST_PKG COMPILE BODY;
ALTER VIEW CUST_VW COMPILE;
ALTER PACKAGE CUST_AUDIT_PKG COMPILE BODY;

Adding HTTP Authentication for a user in Subversion

If you've already got your HTTP Authentication setup (instructions for that can be found here) then you can add a new user (eg. xyz) like this:

$htpasswd2 -m /etc/svn-auth-file xyz

Note that for Apache 2, you use the htpasswd2 command, NOT htpasswd.

Solution to the ORABEL-08021 "partnerlink not found" problem!

I was seeing an ORABPEL-08021 error when calling a Oracle BPEL web service via C# in .Net. Specifically, the error returned was:

<env:Envelope xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
  <env:Header/>
  <env:Body>
    <env:Fault xmlns:env="http://schemas.xmlsoap.org/soap/envelope/">
      <faultcode xmlns="">env:Server</faultcode>
      <faultstring xmlns="">ORABPEL-08021 Cannot find partner wsdl. parnterLink "MyService" is not found in process "MyService" (revision "1.0") Please check the deployment descriptor of the process to find the correct partnerLink name.
      </faultstring>
      <faultactor xmlns=""></faultactor>
    </env:Fault>
  </env:Body>
</env:Envelope>

The problem was that I was using the wrong URI to access the service. I was using:

http://myserver:8888/orabpel/default/MyService/1.0/MyService

and I should have been using:

http://myserver:8888/orabpel/default/MyService/1.0

So, my own silly fault really! Normally I can take the WSDL address (eg. http://myserver:8888/orabpel/default/MyService/1.0/MyService?wsdl) and just drop the "?wsdl" off the end to get the service endpoint. Not with these Oracle BPEL services though. If I had bothered to read the WSDL, I would have seen that the endpoint address is clearly specified. One more thing to note: with an Oracle BPEL service, you can also drop the version number off the end and it will still work, calling the latest version by default. eg:

http://myserver:8888/orabpel/default/MyService

Where should I put my .Net DLL for COM Interop?

I have a .Net DLL which I want to use from VB6 via COM interop. Where should I put it when I deploy it? (look here to see how to make a .Net DLL useable via VB6)

The key thing is that in order to use your .Net dll from VB6 you do need to register the .Net DLL. You don't need to to do anything special in the VB6 program - it doesn't matter how you reference the .Net DLL in your VB6 program. The command to register a .Net DLL is "regasm". This lives under "C:\Windows\Microsoft.Net\Framework\v2.0.50727" (or whatever .Net framework version you have).

There are three options for where to put your .Net DLL:

1. Put it in the GAC. If you want to share the same .Net DLL with more than one VB6 program then you can put it in the GAC (Global Assembly Cache). To do this, you can use an MSI file, or manually, you can copy it to c:\windows\assembly, and then register it via "regasm c:\winnt\assembly\mydotnet.dll".

2. Put it in the EXE folder. If you want the .Net DLL to live in the same place as your VB6 EXE then you can copy it to that folder, and then use "regasm c:\vb6\exe\folder\mydotnet.dll". Note that the .Net DLL has to be in the same folder as the VB6 EXE. So if you have VB6 EXE calling a VB6 DLL which calls your .Net dll then it must go in the EXEs folder - it won't find it in VB6 DLLs folder.

3. Put it in any folder via codebase. If you want the .Net DLL to live anywhere else, you can use use "regasm c:\program files\vanwills\mydotnet.dll /codebase". This will register the .Net DLL to the path you provide. This is a bit like the old VB6 regsvr32 command. So using this we can have the .Net DLL sitting in the "c:\vb6\dll\folder" folder.

The only other point to note is that .Net will always check the GAC first before other locations. So if we have a .Net DLL in the GAC, then even if we register the same DLL somewhere else via the "/codebase" option, it will always use the GAC DLL. You can get around this by changing the version number on the DLL - it will always load the version with the highest number first.

How to switch on log4net internal logging

If you want log4net to show its own internal logging, which is useful to find out where it is looking for your XML configuration file, you can add the following XML to your app.config file:

<configuration>
  <appSettings>
    <add key="log4net.Internal.Debug" value="true"/>
  </appSettings>
</configuration>

Note that if you are using log4net in a DLL, this goes into the app.config file for the EXE that is calling your DLL.

Log4Net using a named config file

Setting up Log4Net with your configuration in the app.config file is pretty straight-forward to do - a quick Google will lead to a number of posts on how to do this.

But if you decide to move your log4net config settings to an external file (convention seems to be "log4net.config") then there are a few misconceptions floating around. There are only two further steps you need to take to achieve this:

1. Copy the <log4net> ... </log4net> section out of your app.config and save it into a new file called log4net.config. You should totally remove it from the app.config file once you feel confident - it is no longer needed.

2. Modify your AssembyInfo.cs file by removing this:

[assembly: log4net.Config.XmlConfigurator
  (Watch = true)]

and replacing it with this:

[assembly: log4net.Config.XmlConfigurator
  (ConfigFile = "log4net.config", Watch = true)] 

Now if you fire up the IDE and run it, your logging should still work. If you don't see any logging, then check that the log4net.config is in the current application path - if you are running from the IDE then that will be where the EXE lives at "../MyProject/bin/Debug/". If you've placed the log4net.config file in your project home folder then you can get it working through the IDE with this:

[assembly: log4net.Config.XmlConfigurator
  (ConfigFile = "../../log4net.config", Watch = true)] 

Note that this will need to be reviewed come deployment time!

OR, even better, just select the config file in the IDE and, in the Properties window, change the "Copy to Output Directory" value to "Copy always". Now when you build it through the IDE it will follow your compiled file around. Nice!

Note that you do NOT need to add log4net.Config.XmlConfigurator.Configure() or log4net.Config.XmlConfigurator.Configure({file name}) to the code in your project! This does a manual configuration which overrides what is in the AssemblyInfo.cs file. If you get the AssemblyInfo.cs parameters right then that is all you need.