The Farrellel Universe

It's not a lot, but a small piece of code I submitted to the DotNetNuke project was accepted today and included in the next release.

I had almost totally forgotten I'd submitted it, but it was included yesterday.

We must celebrate the minor victories :).

About 2 years ago, I changed jobs and started getting paid to write .NET code instead of Java. The language switch was easy to make. Looking back, I think it might have been a little to easy to make. When I've learned new languages, the differences in coding style make it easy to force yourself to learn the techniques that exercise that languages strengths. One problem I had initially with C# was using properties. I found it unnatural not to write accessor methods for class member variables. I've broken that issue (i.e. I stopped trying to make C# into Java), but have run into an issue with code completion in Visual Studio. Occasionally, if I don't code my member variable before coding my public property, I can get the following kind of code to output with code completion. private String id public Id { get { return Id; } set { id = value; } } In this particular case, it was web service code called by another web service, so it was difficult to find the root cause. The above code should make Visual Studio barf at design time. It will always generate an infinite loop at runtime. There should be no way this code is able to compile. This represents a new kind of problem with compilation. Should an IDE add features to the language spec to cause compilation errors that aren't covered by the language spec? I think the answer is yes. It might represent a new way for an IDE to separate itself from the pack. Certainly, with the dominance of virtual machines, IDEs can add runtime checks to ensure stricter language and logical compliance.

[UPDATE] I no longer think this is the case.  IDEs shouldn't add to the language spec.  Therein lies madness :)

Error:

Code generation for property 'xxx' failed.

I encountered this error during design time, in a Windows Forms application, and it was due to bad code. When using static variables with constructors dependent on external objects, you may encounter this type of error (which could be an alert box) while switching between files in Visual Studio. This is especially true if the static variable (with the error) is accessed during form load.

The trick is not in finding the error, the trick is this: You must close and reload the solution or restart Visual Studio to be sure to clear this error. Visual Studio treats a static runtime variable as static at design time.

While trying to generate Salesforce Apex code from a WSDL, I encountered the following error

Unsupported WSDL. Operation 'Create' has more than one output element.

It was not immediately obvious what the solution was, so I'll document it here. The error made me think that the

<definitions><portType><operation name="Create">
or
<definitions><binding><operation name="Create">

elements would have contained multiple <output> elements.

This was not the case. I instead needed to examine the type that was being returned by the element pointed to by the message returned by the <definitions><portType><operation name="Create"> elements (whew!). When I examined that type, I saw that there were multiple sequence elements for the object. Salesforce was freaking out about this. Not sure if this is a bug or architecture design for SalesforceSOA. Please leave comments about your experience.

When deploying multiple instances of DotNetNuke, depending on the environment you are working in, you may encounter an error like the following:

Description: An error occurred during the processing of a configuration file required to service this request. Please review the specific error details below and modify your configuration file appropriately.

Parser Error Message: The entry 'SiteSqlServer' has already been added.

Source Error:

Line 21: <connectionStrings>
Line 22: <!-- Connection String for SQL Server 2005 Express -->
Line 23: <add name="SiteSqlServer" connectionString="Data Source=.\SQLExpress;AttachDbFilename=|DataDirectory|Database.mdf;Integrated Security=True;User Instance=True" providerName="System.Data.SqlClient" />
Line 24: <!-- Connection String for SQL Server 2000/2005
Line 25: <add

This has to do with IIS carrying over connection string keys from other application instances.

A simple remedy is to add the following directive at the beginning of the <connectionString> directive in your web.config file.

<remove name="SiteSqlServer" />

This will remove the offending key before it generates an error.