Visual Basic

18-Jul-05 0:25

I want to configure an environment where i can have a single .net server accessed by multiple developement system.

All the development system should be able to access server's GAC.

All the web project as well as window based projects should run on the server.
Can someone send me technical requirements for the server and if possiable some link to the design approach for the environment.

Christian Graus18-Jul-05 0:32

18-Jul-05 0:32

nitin_ion wrote:
All the development system should be able to access server's GAC.

All the web project as well as window based projects should run on the server.

The only way to do this is to have all your users remote controlling the one machine. I dunno what OS's allow multiple users logged in at once, but it sounds like an incredibly bad idea to me.

Christian Graus - Microsoft MVP - C++

nitin_ion18-Jul-05 0:43

18-Jul-05 0:43

I know that there are so many security concerns.
But what i want is a central .net server where all the custom built assemblies as well as projects are placed so that any developer can refers to it.

Can you suggest a better approach.

Ray Cassick18-Jul-05 10:20

Ray Cassick

18-Jul-05 10:20

I guess you could try to make al your users worok via terminal services.

Eeekk... Hate to think of the type of bopx you would need to keep them productive in that environment though.

George Carlin wrote:
"Don't sweat the petty things, and don't pet the sweaty things."
Jörgen Sigvardsson wrote:
If the physicists find a universal theory describing the laws of universe, I'm sure the a**hole constant will be an integral part of that theory.

My Blog[^]

nitin_ion18-Jul-05 18:03

18-Jul-05 18:03

Visit the post and see the discussion with Dave.

Christian Graus18-Jul-05 12:52

18-Jul-05 12:52

nitin_ion wrote:
ForumVisual Basic / VB.NET
I know that there are so many security concerns.

Why ?

nitin_ion wrote:
But what i want is a central .net server where all the custom built assemblies as well as projects are placed so that any developer can refers to it.

Get all developers to put them in sourcesafe. You ARE using source control, right ?

Christian Graus - Microsoft MVP - C++

nitin_ion18-Jul-05 18:03

18-Jul-05 18:03

Visit the post and see the discussion with Dave.

Christian Graus18-Jul-05 18:07

18-Jul-05 18:07

It all sounds like a mess to me. The only reason I can think for this is that you don't trust your developers.

Christian Graus - Microsoft MVP - C++

nitin_ion18-Jul-05 19:04

18-Jul-05 19:04

If it seems like a mess to you thaen can you suggest a better design for managing multiple projects distributed to multiple teams yet maintain a common development core.

Christian Graus18-Jul-05 19:08

18-Jul-05 19:08

nitin_ion wrote:
If it seems like a mess to you thaen can you suggest a better design for managing multiple projects distributed to multiple teams yet maintain a common development core.

Sure - you create a project that contains your reusable library code, and you put it into sourcesafe ( I said this to you several posts ago ). Every developer can contribute to it, and can build/install it on their machine.

That's a whole lot better than having multiple projects and multiple teams, all fighting for CPU cycles on a single, solitary development box.

Christian Graus - Microsoft MVP - C++

nitin_ion18-Jul-05 20:09

18-Jul-05 20:09

Of course we can use VSS and add reusable code. If we have to use tens of custom build assemblies in different then we have to map each assembly to its location which can be different system and the network policy will play a spoil sport and it's a bad idea to pick assemblies from different locations.
Instead if i want to use that code over multiple projects then i will have to refer that code from it's location so server will act as a central reserviour for that code where all the custom build assemblies will be placed and we can configure the network policy for that machine only.

And I never said that all developers will be working on the server. They will be working on their own local system. Central Server is for placing all the custom libraries and then refering then in different projects as and when required. Every one will be working on their own machine yet they can take the advantage of using custom assemblies and reduce the development time.

More over this will also act as a backup server for the custom assemblies and multiple teams can work on multiple projects at the same time without any one interfering team settings.

What do you think

Christian Graus18-Jul-05 20:17

18-Jul-05 20:17

It sounds like a mess to me. How will you deploy, if you can't even configure a machine to be able to run these components on the local, developer level ?

nitin_ion wrote:
Every one will be working on their own machine yet they can take the advantage of using custom assemblies and reduce the development time.

Why can't those assemblies be on the local machine ? I don't get it.

Christian Graus - Microsoft MVP - C++

nitin_ion18-Jul-05 21:28

18-Jul-05 21:28

It seems that you haven't read my discussion with Dave properly.

Custom assemblies will be installed from the server on the local developer system through a tool.
Server is acting as a bank where all the custom assemblies are located.

Christian Graus19-Jul-05 10:30

19-Jul-05 10:30

Yes, I read your comments to Dave before, and I concur with his response to you.

Christian Graus - Microsoft MVP - C++

Dave Kreskowiak18-Jul-05 6:54

Dave Kreskowiak

18-Jul-05 6:54

I can think of a couple problem with doing this.

First, since code coming from the network isn't trusted by default, you'd have to change your developement machines to full-trust all network code. This would have the effect of taking away your least-priviledged development evnironment. It's easier to develop in an LP environment so you can see your rights problems before you get to testing for them.

Second, if one of these assemblies must be replaced, you'll have to make sure everyone is out of the development environment before you put the new production assembly into place. At least using the same assembly version number anyway. Now, all your developers will have to rebind their references to get this new version to work. But then again, I don't work in a multi-developer environment at all, so I could be wrong here.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

nitin_ion18-Jul-05 18:02

18-Jul-05 18:02

You are right in a sense that we have to mingle with our development env to make this work and there are bound to be some pitfalls.

For your first query.

We don't have to change the settings on the develeoment machines what we can do is build a tool which will take care of code coming from the network.
e.g.

If tommorow i have built a custom library for my project and I want team members of other project to be able to use that library. I can use the tool to install the assembly in the GAC of the server and other teams can use another tool to import the assembly for their project and we will be using VSS so any change in the project will be reflected.
So the LP environment won't be sacrifised.

For your second query.

I am sure that if we refer any custom assembly in our project in .net, it copies that assembly into the bin folder of that project. Also if we modify the assembly and place it againn in the GAC version number will never be the same. Moreover if we have to assemblies of the same name but with different version numbers they both will work fine.
In our case since we will be using a tool to import custom assemblies from server to development environment developers won't have to refer to assembly again.

This is what I think, I could be wrong Let me know what to you think

Dave Kreskowiak19-Jul-05 2:51

Dave Kreskowiak

19-Jul-05 2:51

If all these developers are writing custom assemblies, why is it that they can't be put into a few library projects? I think that's far more managable then having dozens and dozens of different components being referenced. Am I missing something here?

nitin_ion wrote:
I am sure that if we refer any custom assembly in our project in .net, it copies that assembly into the bin folder of that project.

Yes, if you reference the assembly, this is true. But, then your bound to that specific version of it. If, like you said, you develop libaries and components and just allow VS to increment the version numbers with each build, you're screwing yourself. You're going to have lots of different versions of your component copied into the bin folders of how many projects?

nitin_ion wrote:
Also if we modify the assembly and place it againn in the GAC version number will never be the same.

This is the problem! You really don't want a couple dozen versions of your libraries in the GAC! If your going to build a common libarary, I would think this has to be stable before you go building against it. If you want to add new features to the library, great! Develop a new version of the library, test and deploy it. Core libraries are not just "build on the fly" components of your software. If you core libraries aren't solidified, you'll be building a house on a foundation of Jello.

RageInTheMachine9532
"...a pungent, ghastly, stinky piece of cheese!" -- The Roaming Gnome

nitin_ion19-Jul-05 17:36