Hi all,

I am coming from a Visual FoxPro environment and in my VFP applications I used to install the .EXE file on a network share drive where all users will have access to it.

In a .NET application can this also be done? or do I have to install the .EXE file in each computer on a local drive?

Edhy Rijo

Technically, it can be done but it is not recommended and not going to work by default.  The .NET environment, as it ties into the OS, by default restricts any assembly from running on a network drive.  This is considered the Intranet and is not a "trusted" zone.  So first, you will have to create a policy file that gets set or installed on every computer, so at this point you would have already been better off by loading the EXE to the local machine.  To adjust security settings on a local machine to allow an assembly to load off of a network drive click Start->Control Panel->Administrative Tools->Microsoft .NET Framework 2.0 Configuration.

Just to reiterate...this is NOT recommended and this is not how the standards have been designed.  You can do it, but you will have other issues that you will have to address down stream.

Hi Trent,

Once again, thanks for the prompt response!

Then, the recommended way is to install the final application on each computer's local disk and then set the database connection in each one? (could be hard to maintain/setup for several users on a network).

Is there any documentation somewhere with deployment suggestions for a SF project?

Thanks! 

Edhy Rijo

This is a very involved topic and one which we actually cover a bit during our training class due to everyone has a question of some kind regarding deployment.  There are a lot of ways to do this on a large distributed network and many different ways to approach it.  We have some developers who use ClickOnce deployment while others create MSI installations that can be distributed with SMS.

We take a little different approach for our medical software.  We have a server that all clients must talk to and so a "CD" or "DVD" install is only done once on the server.  All clients can then be installed from a network drive.  Once installed the first time, all clients are "self-aware" and automatically update themselves when a new update is made available.

As for the database connection, our medical software looks for the server which runs as a service on the network in order to retrieve its connection information.  The server sends out a broadcast on a UDP port which the client looks for (or can be manually configured if necessary).  A unique GUID is used to identify the correct server.  When the client installs, an INI file has been created during the server install which is used by the client to install itself and look for the server.  This same INI file can be used in many other ways including to specify the network paths, connections, etc.  Then when the client is installed it knows everything and is basically a self-installing MSI.

I know this may be a bit "muddy" on this short post, but there are many different ways to approach this.  Installing to a network drive is not a good idea and will ultimately cause some problems as more users begin accessing the same assemblies.  Also, you will still have to go to every workstation and configure access policies which is more difficult than writing an installation that works within the design specifications of .NET.

Hi Trent,

Thanks for the explanation, it does help since I am new to .NET.  I use InstallAware for all my project's installations and I use the update/patch features of IA which works pretty good for me.

Now I will need to re-design my installations approach to not use a share folder for all users on a network and instead use the recommended approach to install the application on a local drive and handle updates/patches individually which IA does pretty well.  Another change for me is the use of MS-SQL Express instead of VFP tables which also makes sense with the local installation approach since the data will be on a Server/Workstation anyway and access to it is different than VFP.

I am finishing the evaluation of SF and so far, I like it pretty much.

Edhy Rijo

We use InstallAware as well but have created a number of Installer assemblies that run through IA because we ran into a number of road blocks.  But ultimately we are satisfied with their installer as well.

I always like to hear this   Let me know if you have any more questions.

Hi Trent,

I have a couple of small commercial applications in VFP which I am converting to SF, and I am having a configuration issued with how to handle multiple installations at the same customer running from a local network.

In my VFP application I used to install the main .EXE in a network share and using a commercial protection/licensing software I was able to protect and manage a network installation which was running from a common place.  Now with .NET applications installed at each user workstation I am kind of force to issued a license to each workstation and it is very difficult to control en user licenses where I have not access to their installation workstations.

Your approach of using a small Service program on a server or workstation acting as a server for your medical application could be the route I should implement to overcome this issue, since I would simply license the Service application (which will be tide to the Server hardware), instead of the real SF application, so my question is, is your Service approach attached to the Enterprise Server, or it is just another .NET application which in my case should be protected by all means to protect our investment?

P.S.

Sorry for the long post, but I am running out of time and need to find a licensing solution schema soon.

Edhy Rijo

Edhy,



I can't answer much about the whole licensing thing, but I can perhaps clear up what Enterprise Server does. It's sole purpose in life is to act as an intermediary between a SF application and a data source. It doesn't do anything else. I.e. if you have a VFP data source (I'm pretty sure ES works with VFP databases), you could use ES to sit between the application and the VFP database. The app uses a special datasource that points to ES. When the app needs to communicate with the database, the request is packaged up, sent to ES, which then makes the actual request to the database. The response is sent to ES which then packages that up and sends back to the app. This all happens transparently.



Now, the licensing server might use ES itself, if it needed to communicate with a database (or it might just connect directly). The licensing server will typically be a Windows Service (could be a Web Service, I suppose), that manages licenses. After that, I'm not so sure how it would work. It might be something like the license server has license file that allows N number of users to connect, which the server enforces. Or perhaps something more sophisticated, like SF does with activation/deactivation of licenses, via net card MAC address. The important thing is that your likely looking at either a Windows Service or a Web Service as the actual license server.



I know that doesn't actually answer the license question, but hopefully that help clear the mud just a little bit.

Do you people ever sleep?   Oh wait, I am up and working too

You will just need to create a service to which all of your clients will connect as soon as the client app starts.  You will then send over a request to the server asking if there are any open CALs and check to see if the license is valid, etc.  You can use TcpSockets and a listener at the server to manage the connections between the server and the clients.

Embedding the ES is probably not the route you want to take here as this would become a much more complicated (and expensive...which I am cool with ) approach.  But this really has nothing to do with the problem at hand.  At this point, especially at the end of the road here, you will want to take the "keep it simple" approach .  Create a service that is your server which has a tcp listener and all of your licensing logic.  Keep in mind that you will also need to create a console that talks to the service (since the service is a non-UI component).  The other approach is to just create a server app that doesn't run as a service but is still a TcpListener server (just moving the logic from the service to the WinForms console).  The service will work better in the long run though as it will auto-start and play better into the server environment.

Humm, sleep? that sounds familiar

Thanks for the info, will try to go the Service/Console Tcp Sockets way.  The whole idea is to control the customer license and allow then to have as many workstations installed in their network under the same license.

Edhy Rijo