I found a couple of other referenes to this problem here, and it was implied that an assembly cannot be run from a network drive.  However, I want to learn how to keep development directory in network drive in preparation for time when more than one developer is working on same project.

How is it possible to run an assembly from a particular network drive, and directory, not from other places?

Thank you very much,

Alex

I suggest using a source control solution with local working directories.



If you must work directly from a network share, you will need to open up the security a bit using the .NET Configuration tools available in the Control Panel under Administrative Tools.



Hope that helps.

Keith Chisarik

Thank you, Keith.  I have been using Visual FoxPro, and our startup program makes a copy of the project on the fly for each developer which is good enough for a (very) small team.  What Source Control solution do you suggest?  Thanks.

Alex

We use Visual Source Safe, because it fit the budget. It has worked fine for us, I don't know that I would go so far as to recommend. From what I hear Team Foundation version of VS is a lot better and not too $$$ if you have MSDN.




Keith Chisarik

Yeah, Keith is correct.  Team Foundation is far superior to Source Safe.  You actually get a workgroup license which allows 5 developers through the MSDN Subscription with Team Developer Edition.  It is definitely worth the money and you get a lot more with the MSDN subscription than just VS and the Team Foundation stuff.  Highly recommend it!!!

To expand a bit, .NET is designed in to implement much more stringent security environment and ties in to the OS to prevent malicious attacks using security policies.  By default, any network drive is considered a risk and will not execute any .NET assembly.  You can open up your trusts through the .NET 2.0 COnfiguration Manager found in the Control Panel->Administrative tools...however, I recommend against this.  When you have multiple developers accessing the same source files I can guarentee that you will have MAJOR issues and frustrations.  .NET is designed to work best through a source control solution.  At first, coming from VFP, I was not sure that this was a good idea....however, once we started using it it was like tasting candy for the first time   It makes a tremendous difference in cleaning up and creating a standardized, secure, and safe development environment...along with faster access to the source files.

Thank you very much for the advice, Trent and Keith.

By the way Trent, I've had a slow start with Strataframe (and .NET in general) mostly because of indecision: winforms or webforms, fat client or browser interface?  For the application we are starting a fat client makes sense since a LOT of interactive calculations need to be made and state must be kept or recalculations on every hit would kill responsiveness.  My partner believes it is important to achieve dramatic eye-candy (as well as solid behavior of course) to achieve commercial success.  Also we need to become experts at web apps ASAP, so that is an argument in favor of diving into a browser based app.

Would you comment of the above issues, please?  You will be seeing questions about how to blend Infragistics controls with winforms in Strataframe as well as deploying and updating a winform app via internet as we try to get the best of both worlds.

Thank you.

Alex

Sure.  This is something that we cover it some detail in class (which we should be posting or next training dates this week).  In the past there was a huge pendulum swing in the direction of web applications because it was so difficult to make Win form applications scalable and accessible remotely.  So the web was really the only avenue in which to do this.  The pendulum has been swinging back the other way with the advent of web services.  Developing a web applicaiton generally takes 7 times as long as producing a win forms application...and this is with web experience.  There are more factors to take into account such as browser limitations, post-backs, session states, etc.  So to produce an application of any size requires some serious dedication and time.  I will touch on this again in a minute.

Win forms are a more more solid environment in which to develop.  You have more control over the applicaiton, can develop forms, reports, etc much faster than on web forms.  The issue that people generally have with the win forms when creating distributed applications is determining how they will connect to data.  This is what our Enterprise Server provides.  It provides the benefits of developing in Win forms while giving the scalability of web....this technology is referred to in the industry as Smart-Client which I am sure that you are already familiar with.  Though web forms may be used with the ES as well and is especially beneficial for distributed web servers talking to a single point for data access.

There is a time and place for web applications.  Let me give you an example of how we use the web for our medical application.  Our medical application is written as a WinForms application; however, we are going to provide a web portal that allows patients to request refills for the scripts, schedule an appointment, fill out their patient information from home rather than sitting in the doctors waiting room, and review their lab results online.  This extends the application and uses the same BOs, etc that are used on the win form applications.  But this provides a nice extension to the application rather than trying to run the entire app through the web browser.

Finally, we plan to provide a SAAS model (Software as a service) for our medical software as well which allows the end-user to store their data, etc. on our servers and all they have to do is download a client install.  So they run the WinForms on their side (client-side) while all of the data resides on our servers and they get to the data using our Enterprise Server (which is obviously transparent to them).

Hope this makes sense

I'll chime in here with my recommendation for source control: Subversion.



We've been using it for a bit now and it is very good. It is also open source and free It won't integrate as well with Visual Studio as Team Foundation, but it does all that is needed, does it well, fast and is easy to learn. I use Tortoise SVN to do most of my work (extension to windows Explorer), and also AnkhSVN (VS plug-in). Just google Subversion and you'll find it.

Hrm, I'm going to have to check that one out... having a Windows Explorer extension and being able to access source control from outside of VS would be nice... Thanks for the info, Greg.

In all reality, I think TFS only makes sense if you have a huge, distributed team, or you've got an MSDN Premium VS subscription and you only have 5 developers and can make use of the included workgroup version.  Beyond 5 developers, or if you don't have a Team System subscription (there are so many dang levels of MSDN subscription I can't keep them all straight), then finding a good SQL based solution that is cheap and fast is your best bet.