|
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[^]
|
|
|
|
|
Visit the post and see the discussion with Dave.
|
|
|
|
|
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++
|
|
|
|
|
Visit the post and see the discussion with Dave.
|
|
|
|
|
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++
|
|
|
|
|
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.
|
|
|
|
|
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++
|
|
|
|
|
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
|
|
|
|
|
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++
|
|
|
|
|
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.
|
|
|
|
|
Yes, I read your comments to Dave before, and I concur with his response to you.
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
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
|
|
|
|
|
Dave Kreskowiak
If all these developers are writing custom assemblies, why is it that they can't be put into a few library projects
Sure they will be put into as many library projects as possiable. But if there are many assemblies built by as many developers on their own machine then it'll be like snakes & ladders referencing those assemblies. All I said is that if we finalized an assembly release, then that assembly will be placed on the server so that every one can refer it.
Dave Kreskowiak
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?
Yes, this can be a problem in the future and the way i see out of it is that before finalizing any version of an assembly certain version policy has to be in order like change in only major and minor version will be placed otherwise the existing assembly will be modified
or
if you have any suggestion?
Dave Kreskowiak
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
As you have already said
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.
We'll be taking care of it.
Apperciate your feedback
|
|
|
|
|
Ahoy!
I just want to ask, is it possible to control a Visual FoxPro 6 database using Visual Basic 6? Like adding, deleting, and/or editing records in a VFP database.
I’m working on an identification system (barcode, biometrics, etc.) and I wanted to have a VB front-end with a VFP database back-end.
Thanks a lot!
Ric
|
|
|
|
|
The Microsoft Jet database engine, supplied with Visual Basic, gives you the ability to access many types of databases--Microsoft Access databases; other PC-based databases such as dBASE, FoxPro, Paradox, and Btrieve; and any relational database that supports the open database connectivity (ODBC) standard. Visual Basic provides two basic techniques for working with the Jet database engine: the data control and the data access objects (DAO). The data control requires less code, but data access objects are much more flexible.
|
|
|
|
|
Thank you for replying! BTW, do you have a link to a quick ADO tutorial that is specific in using VFP? Thanx a lot!
|
|
|
|
|
Sorry, I wasn't "into" Foxpro so I don't have a specific one, but it's fairly universal.
try here:
Universal Data Access Using ADO
http://internettrash.com/users/fdb/ado.htm
or google it, I'm sure there is a few guy's out there doing the same thing.
|
|
|
|
|
I have developed a windows applicatio using vb.net as MS Access.I have created a setup program using the package and deploymnet wizard.But I am not able to install it on a system with Windows ME OS.I can install it on Windows XP and Wndows 2000.What could be the problem?The OS I use is Windows 2000.Can anyone help me.Thanks in advance.
|
|
|
|
|
What do you mean by 'you are not able to install it' ? It won't install ? It won't run ? Is the .NET framework installed on this machine ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
dot net framework is installed in the target machine.not able to install means i cud not able to run the setup program in windows ME.
|
|
|
|
|
An installer can be created to target specific machines - perhaps your installer thinks it is only for 2000/XP ? What happens, do you get an error ? A crash ? Nothing happens ?
Christian Graus - Microsoft MVP - C++
|
|
|
|
|
when I double click the windows installer file An Open With Dialog box is opened and I am not sure how to proceed from there.Please help.
|
|
|
|
|
Ah - the lights come on. You need to install the msi installer itself, ME does not know what to do with an msi file otherwise.
Christian Graus - Microsoft MVP - C++
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
