Velocity Reviews - Computer Hardware Reviews

Velocity Reviews > Newsgroups > Programming > ASP .Net > Confused and bewildered.

Reply
Thread Tools

Confused and bewildered.

 
 
DJ Miller
Guest
Posts: n/a
 
      07-30-2003
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.


 
Reply With Quote
 
 
 
 
CT
Guest
Posts: n/a
 
      07-31-2003
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.

--
Carsten Thomsen
Enterprise Development with Visual Studio .NET, UML, and MSF
http://www.apress.com/book/bookDisplay.html?bID=105
"DJ Miller" <(E-Mail Removed)13> wrote in message
news:O%(E-Mail Removed)...
> 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.
>
>



 
Reply With Quote
 
 
 
 
DJ Miller
Guest
Posts: n/a
 
      07-31-2003
That helps, thanks. Didn't even think about that when I set up SourceSafe.
That's one down.

"CT" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
> --
> Carsten Thomsen
> Enterprise Development with Visual Studio .NET, UML, and MSF
> http://www.apress.com/book/bookDisplay.html?bID=105
> "DJ Miller" <(E-Mail Removed)13> wrote in message
> news:O%(E-Mail Removed)...
> > 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.
> >
> >

>
>



 
Reply With Quote
 
Kalyan
Guest
Posts: n/a
 
      08-28-2003
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


"CT" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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.
>
> --
> Carsten Thomsen
> Enterprise Development with Visual Studio .NET, UML, and MSF
> http://www.apress.com/book/bookDisplay.html?bID=105
> "DJ Miller" <(E-Mail Removed)13> wrote in message
> news:O%(E-Mail Removed)...
> > 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.
> >
> >

>
>



 
Reply With Quote
 
DJ Miller
Guest
Posts: n/a
 
      09-04-2003
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...

"Kalyan" <(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> 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
>
>
> "CT" <(E-Mail Removed)> wrote in message
> news:(E-Mail Removed)...
> > 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.
> >
> > --
> > Carsten Thomsen
> > Enterprise Development with Visual Studio .NET, UML, and MSF
> > http://www.apress.com/book/bookDisplay.html?bID=105
> > "DJ Miller" <(E-Mail Removed)13> wrote in message
> > news:O%(E-Mail Removed)...
> > > 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.
> > >
> > >

> >
> >

>
>



 
Reply With Quote
 
 
 
Reply

Thread Tools

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are Off


Similar Threads
Thread Thread Starter Forum Replies Last Post
confused between char and char* and connection to Arrays arnuld C++ 19 03-30-2007 04:42 AM
DVD Verdict reviews: ULTIMATE PARTY COLLECTION: DAZED AND CONFUSED / FAST TIMES AT RIDGEMONT HIGH and more! DVD Verdict DVD Video 0 12-07-2004 10:11 AM
MPLS TE: Confused by IGP and RSVP. Catelecom Cisco 0 12-29-2003 12:57 AM
getting confused and going crazy Larry Tate ASP .Net 3 12-21-2003 09:40 PM
Urgent: Catch 22 here and I'm confused John ASP .Net 0 07-03-2003 11:48 PM



Advertisments