Confused and bewildered.

[DJ Miller]

There's got to be an easier way to do this.

We are building a new web application in .Net that has ASP.Net pages that
call COM+ objects (written in VB.Net), which in turn call other COM+ objects
(VB.Net), which use ADO.Net to talk to a SQL Server. Many of the components
inherit a common interface. At least, that's our goal.

At the moment, everything is in one single solution. This makes things very
inconvenient, because when one developer wants to add a project (like a new
object), they must check out the solution file, which only they have access
to; and no other developer can add projects to the solution until that file
is checked back in.

The objects also don't seem to be able to call each other when in COM+. The
projects are set up for lazy registering (Inherits ServicedComponent) for
ease of debugging, except that the moment one object tries creating another,
the other does get registered into COM+ but the first claims it can't create
the second. (All objects are created with zero security, to run as the
"Interactive User", and on our dev boxes, that means local administrator.)
Also, stepping through the code won't step into code for objects in COM+.
We currently have the "Inherits ServicedComponent" line commented out, so
COM+ is not getting used. (Every object is strongly named by referencing a
common .snk file; does each object require its own .snk? From what I've
read, the answer is no, and I hope that's right, because there is already a
series of tedious steps for creating a new object. Also, every object has
EventTracking enabled.)

Also, it seems odd that, as I create an object that references another, I
have to set a reference to that other's project, and the "Copy Local"
property must be set to True. Thus, when I build my project, I notice that
my BaseData component's dll file exists in its bin folder, the bin folder of
all objects that call it, the bin folder of all objects that call those
objects, and so forth. While I suppose it might make some sense in the
non-COM+ world (which I suppose is where I am now), why is this required
even when COM+ is used? (If I try setting that to False when referencing my
"entry" COM+ component, I get errors trying to create it.) Is it because I
haven't figured out how to get COM+ working correctly (previous paragraph)?

Speaking of COM+ problems, I can't create a constructor method to use
construction strings. If I "Enable object construction", I get an error
that no constructor method was found. Examples I found say one must
overload the public method Construct(or?), but I get an error in the IDE
saying the Construct method is Protected, not Public.

Also, is there a way to segregate the objects somewhat? Right now, if I
make a change to an object three levels deep, even if the interface doesn't
change, the IDE recompiles that object and all objects that call it. Why is
that even necessary? Isn't one of the primary points of COM that one can
simply replace a single component without having to re-distribute the entire
app?

This is just a quick summary of the more immediate concerns we've had
developing in .Net. We haven't even gotten to the step of deploying this
thing on a common web server for testing, which I'm sure will have its own
set of questions.

Where can I get answers to these questions? This is really rather painful,
even if the actual coding part of it isn't.

 

[CT]

Well, for starters, wouldn't it be an idea tog look at shared check-outs in
source control for your solution file? At least this way you won't have the
problem of only one developer checking the solution file out at a time.

 

[DJ Miller]

That helps, thanks. Didn't even think about that when I set up SourceSafe.
That's one down.

 

[Kalyan]

Regarding the solution file, one work around i used is to keep the sln file
checked out by only 1 user, and others can keep it in editable mode. So the
messsage "Check out" for sln file wont be displayed, you can continue
normally with other files. If you need to all new projects / pages /
classes it needs to be done in central place. Mine was a small group, and
so we managed to live with this setup.

Even i encountered some of the problems in COM+ that you encountered. I
havent found a solution for that yet.
Hope this helps.

Cheers,
Kalyan

 

[DJ Miller]

Well, I did manage to fix most of them.

Enabling multiple checkouts was the first solution (so far it has worked
quite well).

Each of the objects, instead of having them reference the other projects
directly, once I compiled them, I have them reference the
\bin\<objectname.dll> of the project they're referencing. And, the property
for each reference is set for "Copy Locally" = False. Then I have the
dependencies set up in the main solution file, so when I compile them
they're all compiled in the proper order.

I also have in the Assembly.vb file explicitly set the version number.
Since my interfaces don't change, it's not worth the headache of the
versioning nightmare trying to tell an object it's ok to use v1.0.0.1234
instead of v1.0.0.1233 just to fix a little bug when the interface doesn't
change.

I created a series of batch files that copy each and every compiled dll into
the gac, using gacutil. (One batch file registers files from \obj\Debug,
one from \bin -- using the ones from \obj\Debug allows me to step through
the code. Another batch file uses regsvcs to register each one into COM+ --
note that I'm registering the ones that are in the \Winnt\Assembly\GAC
folder. <rant>It completely sucks I have to do this for my VB objects. Why
they don't support post-build scripts in VB is completely insane. "Here, we
spent all this time and research into making VB more capable of creating
COM+ objects. Oh, but this really useful tool that would automatically set
up the object when you compile, you don't get that."</rant>

I have another solution set up separate from the main solution. If I want
to edit one object, I add that project to the solution independently. I can
make my changes and recompile at will, and since the references are linked
to other precompiled dlls and I don't have dependencies set up in this new
solution, it doesn't complain. The only issue is, after recompiling, I have
to re-register the dll into the gac (shutting down the associated COM+
application if necessary, so gacutil can actually perform the dll
overwrite).

Debugging and stepping through code is still a bit of a pain, but not too
difficult. I load the project in my second solution (the one I use for
editing one object at a time), start the COM+ application that contains the
object I'm interested in, make note of the PID under which that application
is running, and attach the debugger to the dllhost process with the same
PID. Then I set breakpoints all over the source code and run whatever
application I need to test it (which is usually a little testing app I have
in that little solution file).

So that's where I am. Still no answer on the COM+ Constructors, though,
which I think is the last of my major problems...