|
web
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Best Practices2003. We are about a month away from go-live for phase 1, second phase is rather short and all work should be completed in the next 2 months. Looking back on problems encountered, we want to learn from this project. FWIW, we are nearly on time with the original time line (only off by about a month), and we actually added more functionality than the original specs called for. In this application, we have several projects we created for simple, reusable functionality (such as a dll that handles BLOB attachements, a dll to handle user preferences, a dll to handle system messaging, etc.) These projects are a mixture of VB and C#, with the output for all being a dll that the application's exe calls. It has worked really well for us and we expect that most of these dll's will be reused in upcoming projects. That being said, we did have some problems. We did this project mostly with 2 developers. We did the project WITHOUT a source control program (that was interesting) because management hasn't bouught in to source control yet. (That has finally changed and we are testing SourceSafe). The dlls were included in the main project as dll's rather than as a project. I did this because I wanted to keep the solution pared down but I'm not sure that was the best way to do it. Any thoughts? Any comments on referencing a dll vs referencing a project in the solution? Going forward we plan to use source control. We are testing Visual SourceSafe, anyone want to add their 2 cents either for or against this? Any suggestions on other products we may want to consider? We will be converting to .NET 2005 soon, but the cost of Team Edition and a dedicated Team Foundation Server is too pricey. It was suggested we look at CVS and/or Subversion. I'm a little familiar with CVS and wasn't that impressed with it. Anyone with experience with either of them? Sorry for the length of the post, but I wanted to provide as much information as possible and I hope to start a healthy dialog with anyone interested in sharing their experiences. Thanks, Will I Am Reference a DLL is the best and good idea. You are ok on that...
My thoughts on VSS.. 1. It is a very good tool, works well for small to medium projects I mean with upto 10 developers 2. VSS works well with situations of Single User checking out Single file... Multiple Users checking out Single files.. I am not really sure I have had bad experiences... I would avoid that with VSS, or not even consider VSS, if that happens to often in the project 3. VSS is also tricky.. sometimes I have lost data keeping in it.. So you will have to back the directories where the VSS is having the Data files 4. If I used VSS, I would also try to keep a hard back for a couple of versions.. The real good practice that I found useful is to use regions in code... or ..CS or .VB files.. Very helpful and good practice.. VJ Show quoteHide quote "BK" <bkunn***@hotmail.com> wrote in message news:1145466161.194749.223270@i39g2000cwa.googlegroups.com... > We've got a fairly large scale development process under way in .NET > 2003. We are about a month away from go-live for phase 1, second phase > is rather short and all work should be completed in the next 2 months. > > > Looking back on problems encountered, we want to learn from this > project. FWIW, we are nearly on time with the original time line (only > off by about a month), and we actually added more functionality than > the original specs called for. > > In this application, we have several projects we created for simple, > reusable functionality (such as a dll that handles BLOB attachements, a > dll to handle user preferences, a dll to handle system messaging, etc.) > These projects are a mixture of VB and C#, with the output for all > being a dll that the application's exe calls. It has worked really > well for us and we expect that most of these dll's will be reused in > upcoming projects. > > That being said, we did have some problems. We did this project mostly > with 2 developers. We did the project WITHOUT a source control program > (that was interesting) because management hasn't bouught in to source > control yet. (That has finally changed and we are testing SourceSafe). > The dlls were included in the main project as dll's rather than as a > project. I did this because I wanted to keep the solution pared down > but I'm not sure that was the best way to do it. Any thoughts? Any > comments on referencing a dll vs referencing a project in the solution? > > Going forward we plan to use source control. We are testing Visual > SourceSafe, anyone want to add their 2 cents either for or against > this? Any suggestions on other products we may want to consider? We > will be converting to .NET 2005 soon, but the cost of Team Edition and > a dedicated Team Foundation Server is too pricey. It was suggested we > look at CVS and/or Subversion. I'm a little familiar with CVS and > wasn't that impressed with it. Anyone with experience with either of > them? > > Sorry for the length of the post, but I wanted to provide as much > information as possible and I hope to start a healthy dialog with > anyone interested in sharing their experiences. > > Thanks, > > Will I Am > BK,
For assemblies that are used by many unrelated applications I use file references. For assemblies that are only used by one application I add the corresponding project to the solution and use project references. A typical folder hierarchy for an application may look like the following. WizbangApplication WizbangApplication WizbangApplication.DatabaseStuff WizbangApplication.LoggingStuff WizbangApplication.MathAlgorithms WizbangApplication.Setup Resources In the above structure the main WizbangApplication folder will contain the .sln file and that's about it other than the subfolders. The WizbangApplication subfolder will contain the project that outputs the exe. The other subfolders will contain the projects that output the dlls or msi. The Resources subfolder contains all 3rd party dlls, in-house dlls that aren't specific to the WizbangApplication, image files, or other resources that may need to be compiled into the application, but are not specific to the application. When you check things into your source code control provider make sure it compiles. The most annoying thing to me when I transition to a new project that's already in the works is getting the latest version of the source code and spending 2 hours figuring out build orders, dll dependencies, versioning issues, syntax errors, etc. If you get things checked in correctly it should be a piece of cake to automate nightly builds and unit tests. I have a deep dislike for SourceSafe despite being forced to use it for the last 7 years. CVS or Subversion are better IMO. But, it does the job...most of the time :) Brian BK wrote: Show quoteHide quote > We've got a fairly large scale development process under way in .NET > 2003. We are about a month away from go-live for phase 1, second phase > is rather short and all work should be completed in the next 2 months. > > > Looking back on problems encountered, we want to learn from this > project. FWIW, we are nearly on time with the original time line (only > off by about a month), and we actually added more functionality than > the original specs called for. > > In this application, we have several projects we created for simple, > reusable functionality (such as a dll that handles BLOB attachements, a > dll to handle user preferences, a dll to handle system messaging, etc.) > These projects are a mixture of VB and C#, with the output for all > being a dll that the application's exe calls. It has worked really > well for us and we expect that most of these dll's will be reused in > upcoming projects. > > That being said, we did have some problems. We did this project mostly > with 2 developers. We did the project WITHOUT a source control program > (that was interesting) because management hasn't bouught in to source > control yet. (That has finally changed and we are testing SourceSafe). > The dlls were included in the main project as dll's rather than as a > project. I did this because I wanted to keep the solution pared down > but I'm not sure that was the best way to do it. Any thoughts? Any > comments on referencing a dll vs referencing a project in the solution? > > Going forward we plan to use source control. We are testing Visual > SourceSafe, anyone want to add their 2 cents either for or against > this? Any suggestions on other products we may want to consider? We > will be converting to .NET 2005 soon, but the cost of Team Edition and > a dedicated Team Foundation Server is too pricey. It was suggested we > look at CVS and/or Subversion. I'm a little familiar with CVS and > wasn't that impressed with it. Anyone with experience with either of > them? > > Sorry for the length of the post, but I wanted to provide as much > information as possible and I hope to start a healthy dialog with > anyone interested in sharing their experiences. > > Thanks, > > Will I Am Thanks for your input.
Your directory structure is basically the same as what we use, but we don't have a resource folder. I think that would resolve one of our problems we have with keeping a uniform place for additional dll's we use in a solution where we don't have the source code or don't need to maintain the source code as part of the solution. As for SourceSafe, more and more people are recommending we stay away from it. I'm leaning toward SourceGear now. Does CVS have a GUI interface into the administration side of it? I don't really care if our SCC is integrated, it's not a big deal to check in and check out code from a seperate window before/after working on the code. Is this attitude going to get me in trouble down the road? Bill Hi,
About VS.NET and Source Code Control (SCC) integration, best practices and so on, see this section of my web site: http://www.mztools.com/resources_net_developers.htm#SCC Resources about Visual Studio .NET and Source Code Control (SCC) integration I wouldn´t recommend SourceSafe 6.0, it can cause corruption problems. Maybe SourceSafe 2005 fixes that. TFS may be overkill for only two persons, so you may also take a look at (I haven´t use them but they have good reputation): - SourceVault (http://www.sourcegear.com/vault/index.html). It's free for 1 developer. - Perforce (http://www.perforce.com/). It's free for up to 2 developers. -- Show quoteHide quoteBest regards, Carlos J. Quintero MZ-Tools: Productivity add-ins for Visual Studio You can code, design and document much faster: http://www.mztools.com "BK" <bkunn***@hotmail.com> escribió en el mensaje news:1145466161.194749.223270@i39g2000cwa.googlegroups.com... > We've got a fairly large scale development process under way in .NET > 2003. We are about a month away from go-live for phase 1, second phase > is rather short and all work should be completed in the next 2 months. > > > Looking back on problems encountered, we want to learn from this > project. FWIW, we are nearly on time with the original time line (only > off by about a month), and we actually added more functionality than > the original specs called for. > > In this application, we have several projects we created for simple, > reusable functionality (such as a dll that handles BLOB attachements, a > dll to handle user preferences, a dll to handle system messaging, etc.) > These projects are a mixture of VB and C#, with the output for all > being a dll that the application's exe calls. It has worked really > well for us and we expect that most of these dll's will be reused in > upcoming projects. > > That being said, we did have some problems. We did this project mostly > with 2 developers. We did the project WITHOUT a source control program > (that was interesting) because management hasn't bouught in to source > control yet. (That has finally changed and we are testing SourceSafe). > The dlls were included in the main project as dll's rather than as a > project. I did this because I wanted to keep the solution pared down > but I'm not sure that was the best way to do it. Any thoughts? Any > comments on referencing a dll vs referencing a project in the solution? > > Going forward we plan to use source control. We are testing Visual > SourceSafe, anyone want to add their 2 cents either for or against > this? Any suggestions on other products we may want to consider? We > will be converting to .NET 2005 soon, but the cost of Team Edition and > a dedicated Team Foundation Server is too pricey. It was suggested we > look at CVS and/or Subversion. I'm a little familiar with CVS and > wasn't that impressed with it. Anyone with experience with either of > them? > > Sorry for the length of the post, but I wanted to provide as much > information as possible and I hope to start a healthy dialog with > anyone interested in sharing their experiences. > > Thanks, > > Will I Am > Thanks for the input. We actually have more than 2 developers, there
are 20+ in the department, but about 8 of us work in .NET. I am leaning toward SourceGear and plan to put a test in place soon for it. Thanks for the links. Bill 
Other interesting topics
|
|||||||||||||||||||||||
