Confused and bewildered.

Discussion in 'ASP .Net' started by DJ Miller, Jul 31, 2003.

  1. DJ Miller

    DJ Miller Guest

    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.
     
    DJ Miller, Jul 31, 2003
    #1
    1. Advertising

  2. DJ Miller

    CT Guest

    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" <13> wrote in message
    news:O%...
    > 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, Jul 31, 2003
    #2
    1. Advertising

  3. DJ Miller

    DJ Miller Guest

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

    "CT" <> wrote in message
    news:...
    > 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" <13> wrote in message
    > news:O%...
    > > 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.
    > >
    > >

    >
    >
     
    DJ Miller, Jul 31, 2003
    #3
  4. DJ Miller

    Kalyan Guest

    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" <> wrote in message
    news:...
    > 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" <13> wrote in message
    > news:O%...
    > > 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.
    > >
    > >

    >
    >
     
    Kalyan, Aug 28, 2003
    #4
  5. DJ Miller

    DJ Miller Guest

    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" <> wrote in message
    news:...
    > 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" <> wrote in message
    > news:...
    > > 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" <13> wrote in message
    > > news:O%...
    > > > 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.
    > > >
    > > >

    > >
    > >

    >
    >
     
    DJ Miller, Sep 4, 2003
    #5
    1. Advertising

Want to reply to this thread or ask your own question?

It takes just 2 minutes to sign up (and it's free!). Just click the sign up button to choose a username and then you can ask your own questions on the forum.
Similar Threads
  1. John
    Replies:
    0
    Views:
    287
  2. Larry Tate

    getting confused and going crazy

    Larry Tate, Dec 21, 2003, in forum: ASP .Net
    Replies:
    3
    Views:
    514
    Larry Tate
    Dec 21, 2003
  3. Mark Fenbers

    Bewildered graphs

    Mark Fenbers, Jul 5, 2003, in forum: Python
    Replies:
    5
    Views:
    582
    Tim Churches
    Jul 6, 2003
  4. arnuld
    Replies:
    19
    Views:
    726
    Jacek Dziedzic
    Mar 30, 2007
  5. John Doe
    Replies:
    3
    Views:
    328
    Tassilo v. Parseval
    Feb 17, 2004
Loading...

Share This Page