A Day in the Life

A day in my life. Thoughts on leadership, management, startups, technology, software, concurrent development, etc... Basically the stuff I think about from 10am to 6pm.

6/01/2007

Fun with vbc.exe...snore

I created a .NET 1.1 and a .NET 2.0 VB.NET sample for the Digipede Network. One of the requirements for our sample code is that the samples can be built from the command-line. The first thing I had to do for this test was to make sure that I had an open Command Prompt window with the PATH correctly containing only .NET 1.1 and VS2003 references.

Then it was time to start building my batch file. Since my sample is based on a C# sample I started by copying the build.bat file from the C# sample, thinking that that would work just fine after I changed a few things. Boy was I wrong.

.NET 1.1/VS2003

My VB.NET project builds fine when built inside VS2003. This is what my batch file started out looking like:

copy ..\..\Digipede.Framework.dll 
copy ..\..\Microsoft.Web.Services2.dll

cd MonteCarloLibrary
vbc.exe /t:library /out:MonteCarloLibrary.dll
/r:..\Digipede.Framework.dll piworker.vb

cd ..
copy MonteCarloLibrary\MonteCarloLibrary.dll

vbc.exe /t:winexe /out:MonteCarloPi.exe
/r:Digipede.Framework.dll /r:MonteCarloLibrary.dll
MainForm.vb

This didn't work and generated a plethora of bugs.

The build command for the MonteCarloLibrary changed to look like this:

vbc.exe /t:library /out:MonteCarloLibrary.dll 
/r:..\Digipede.Framework.dll /r:Microsoft.VisualBasic.dll
/r:System.Data.dll piworker.vb

Apparently the IDE automatically includes the Microsoft.VisualBasic.dll and System.Data.dll files for you and when compiling on the command-line you have to reference them yourself. Additionally, I had to make changes to my code so that my Imports list contained everything I would need. That list changed from:

Imports Digipede.Framework
Imports Digipede.Framework.Api

to:

Imports System
Imports System.Data
Imports System.XML
Imports System.Runtime.Serialization
Imports Digipede.Framework
Imports Digipede.Framework.Api

These changes got me around most of the BC30002 errors.

The next thing that was a problem was that in my executable I referenced my DLL as MonteCarloLibrary.MonteCarloLibrary.PiWorker. This compiled just fine in the IDE but not from the command-line. When compiling from the command-line I got the following error:

MainForm.vb(468) : error BC30002: Type 
'MonteCarloLibrary.MonteCarloLibrary.PiWorker' is not defined.
Dim jobTemplate As JobTemplate = JobTemplate.NewWorkerJobTemplate
(GetType(MonteCarloLibrary.MonteCarloLibrary.PiWorker))

This puzzled me for awhile until I changed my code to be:

Dim jobTemplate As JobTemplate = JobTemplate.NewWorkerJobTemplate
(GetType(MonteCarloLibrary.PiWorker))

Notice I deleted the Namespace 'MonteCarloLibrary'. This change compiled just fine from the command-line but not from the IDE. What was going on?

It seems that in the IDE my MonteCarloLibrary had a Root namespace defined in the project. Now I don't remember ever setting this so I don't know if I put it in or the IDE put it in, regardless...there it was. And that, so to say, was the root of my problem.



I deleted the Root namespace. Changed my code to remove the namespace reference and was then around that problem.

Onward...though not upward.... As you can see I've switched over to errors reported by my executable WorkerLibraryFormsVB.exe

vbc : error BC30420: 'Sub Main' was not 
found in 'WorkerLibraryFormsVB'.

A quick Google search yielded no valid answer so I decided to bite the bullet and actually look at the VB.NET compiler settings by typing:

vbc /?

This looked good:
/main:
option is defined as

Specifies the Class or Module that contains Sub Main. It can also be a Class that inherits from System.Windows.Forms.Form. (Short form: /m)

New command-line:

vbc /t:winexe /main:MonteCarloForm 
/out:WorkerLibraryFormsVB.exe /r:Digipede.Framework.dll
/r:MonteCarloLibrary.dll MainForm.vb

Which got past the ‘Sub Main’ error but there were still more....

vbc: error BC30451: Name 'MessageBox' is not declared.

To get around the problem above you'll need to do two things. The first thing to do is to verify that you have

Imports System.Windows.Forms

at the top of your file. (In this case I added the Imports command to the top of MainForm.vb)

The second thing is to add additional references to your build command-line:

vbc /t:winexe /main:MonteCarloForm /out:MonteCarloPi.exe 
/r:Digipede.Framework.dll /r:MonteCarloLibrary.dll
/r:System.Windows.Forms.dll /r:Microsoft.VisualBasic.dll
/r:System.Data.dll MainForm.vb

I had one error left and that was:

\MainForm.vb(534) : error BC30451: Name 'ControlChars' 
is not declared.

Dim errMsg As String = [String].Format("Job submission
failed with error:" + ControlChars.Lf + "{0}",
e.Error.Message)

I changed the line to read:

Dim errMsg As String = [String].Format
("Job submission failed with error:" +
Microsoft.VisualBasic.ControlChars.Lf + "{0}",
e.Error.Message)

Notice I told the compiler EXACTLY where to find ControlChars....and then everything was just fine.

Here is the new, working build.bat file:

copy ..\..\Digipede.Framework.dll 
copy ..\..\Microsoft.Web.Services2.dll

cd MonteCarloLibrary
vbc.exe /t:library /out:MonteCarloLibrary.dll
/r:..\Digipede.Framework.dll /r:Microsoft.VisualBasic.dll
/r:System.Data.dll piworker.vb

cd ..
copy MonteCarloLibrary\MonteCarloLibrary.dll

vbc.exe /t:winexe /out:WorkerLibraryFormsVB.exe
/r:Digipede.Framework.dll /r:MonteCarloLibrary.dll
/r:Microsoft.VisualBasic.dll /r:System.Data.dll
/r:Mscorlib.dll /r:System.dll
/r:System.Windows.Forms.dll /r:System.Drawing.dll
/main:MonteCarloForm MainForm.vb

.NET 2.0/VS2005

Once testing indicated that I had the .NET 1.1/VS2003 version working I then copied my new build.bat file over to the .NET 2.0/VS2005 project. I made the necessary code changes with my Imports and namespace, and then tried to build. I got the following warning:

warning BC42025: Access of shared member, 
constant member, enum member or nested type through
an instance; qualifying expression will not be evaluated.

Dim jobTemplate As JobTemplate = jobTemplate.NewWorkerJobTemplate
(GetType(MonteCarloLibrary.PiWorker))

Although not an error, only a warning, I don’t like to see either in my output and it needed to go. This is what my code looked like to me in VS2003:

Dim jobTemplate As JobTemplate = 
JobTemplate.NewWorkerJobTemplate(GetType(
MonteCarloLibrary.PiWorker))

Notice that in the error message it is jobTemplate.NewWorkerJobTemplate and in my code it is JobTemplate.NewWorkerJobTemplate. Damned if VB wasn’t making my capital J a lowercase j. It was actually funny (for all of 30 seconds) to change the lower case j to an upper case J and watching the IDE change it back for me. It was like a magic trick; only after the first few laughs it wasn't funny any more. Quite frankly I have better things to do than waste my time on this kind of crap. A quick look through the VS2005 Options pages and nothing jumped out to make this stop. So I changed my variable name to myJobTemplate.

Conclusion
One thing that would have been really handy is if the IDE would have displayed the command-line it was using. This option is available for other languages why not VB.NET?

1 Comments:

At June 04, 2007 11:20 AM, Anonymous Brian said...

Pain in the ass...

 

Post a Comment

Links to this post:

Create a Link

<< Home