I'm somewhat new to deploying ClickOnce manifests, first off. I know the basics of how to publish to an app server, which then lets every use the newest version (after setting to check for updates before running the application).
We have multiple VB.Net applications stored on our app server, that cover a lot of different areas of the company. However, all of them connect to our Oracle database in the same way. So, my thought was to create a DLL containing commonly used functions, such as decrypting and reading our connection string, among some very common SQL functions/statements that we use a lot. Then, instead of copying and pasting the same code into each .Net program, it would be stored in one place. Of course, the major benefit to this would be that if we change the method we use to connect to the database, or need functions modified/added, we don't need to open each program, paste it in, and .republish
So, I did a test where I took a program that I wrote, added the DLL to it and tested it out. It works great. Then I took the source code of the DLL, made a change to show a message box at the beginning of a function, rebuilt the DLL, and dropped it in place of the copy that was being referenced in the test program. When I run the program, it's still using the original DLL without the message box code.
My question is, how could I accomplish what I would like to do without having to republish each and every .Net program that uses this DLL whenever a change is made to it?
Option 1
Instead of publishing your dll library via click once, Put a web service wrapper around your dll class library. Each Click once application will have a reference to the web service which will run on a web server.
Your code in the dll will then be running on the web server. Any changes to the dll code will only need to be updated on the web server. You'll have to be careful to keep the interface changes to a minimum.
Option 2
push out the dll as an separate MSI install. Reference the dll in your click once apps code and make sure you don't deploy the dll with the click once install. Changes to the dll will be pushed out separately.
Related
Currently I am working on the development of CATIA by C++ and Automation Interface. Everything is based on local environment of every client machine. After updating our program, clients have to deploy it manually after receiving the updated one.
We are considering if there is a way we could put our program on the server, and we assign the authorizations to the specific clients to access it. They still need install CATIA in their local machine, but our customization programs are on the website.
Our program is based on COM component, so this is a priority.
Any feasible idea?
Thanks in advance.
I'm developing programs for Catia too (VB .NET) and there might be a solution to use webbrowser to manage the programs but I'm unable to help with that :)
Instead what I use is selfdeveloped feature which updates the tools exe files on client from network storage or FTP.
Think of it as algorithm which searches certain folders or storage and decides if the program should update itself and lets the user know. Then you run the updater which is not part of the tool (separate program) and he make the changes on the main exe (copy files, config, remove add etc.)
This way you don't have to take care of the deployment and the user only clicks the update. That's it :)
At a client of mine, in-house applications are all located on a network share. Users create shortcuts to the required applications from the network share so we can easily make sure everyone uses the latest version.
This works fairly well, although we often have an issue when users are still using applications when we'd like to release a new version. For most applications, we'd forcibly remove all the file locks on the server and release the new version. Not a very elegant solution, especially since we need assistance from another department for this.
For newer applications, I've developed a cleaner solution, where the application intermittently checks if it's still the most recent release. If it isn't, it shows a message to the user, asking him to quit the application at first convenience, or within 3 minutes. After 3 minutes, the application quits itself and all is well. However, some users will immediately try to re-start the application. The application will then show a simple MessageBox telling the user this version is currently not supported. My problem is this: while this MessageBox is visible, my executable is still locked.
I'm looking for any of the following solutions:
Releasing all locks on the current assembly files from within code
Showing a message box that lingers after the current assembly has exited
This is exactly precisely the problem that .NET ClickOnce deployment is meant to solve. Users have a shortcut they can click, the latest version is downloaded on application start, and there are no server-side executables to be locked if a user leaves their process open.
ClickOnce Deployment Overview
HowTo:Publish a ClickOnce Application
I have a very strange issue that i cannot figure out.
First i have a WCF service 4.0 done in VS2010.
the service have couple methods that return string array, datatable and such.
some of them use function from C++ dll throught [dllimport]
i made a test console to test everything. when i run the WCF from visual studio and use the generated path it works wonderfully.
now here is where it become strange. if i open my local IIS create a new application and point to my VS source code the WCF i can see it perfectly.
now using the http path from IIS local instead i refresh the methods all seems correct. But when i run my test app i can call any unction without any problem EXCEPT anyone using DLLIMPORT functions. they ALL crash and cannot trace even by tracing CES exceptions.
Doing line by line logging show that the exception is really on the call of those functions
the DLL in question is the same and the path is hardcoded for my computer since still in test phase and the folder is c:\DLL\mylib.DLL so nothing to do with shadow copy IIS/visual studio do when you actually run. also DLL reference by name withotu path even if it's in sys32 doesnt work.
Any clue ?
also. 32bit, changing app pool level right access on folder, full admin on machine already too. all tried but unsuccessful.
Edit: adding to all that since i haven't made this clear, it's not my first WCF real setup. i've already made alot of services before and deployed them myself (probably somewhere around 50-60 services). I am asking because i have never seen this issue before and i tried all tricks i knew and could find on the internet and resource people i know.
We have decided to incorporate the whole service in the WPF project locally since it work as long as IIS is not hosting. but this is really not a good thing as this data and work should NOT be done on client side but instead on server side. Right now it's fine since the software that need to use this is not released to public yet so it isn't critical.
Next option will be net TCP/IP windows service hosted on the web server if i don't find anything else.
We decided to go trough the trouble of having to hard code the logic in the main software and get away from web services for this issue. we will have to deal with updating, installing unregister and re register unmanaged DLL by hand somehow but at least it works.
we have added over 5 web services since that happen and no problem with them but again none of them use DLL imports.
i have an application written in VFP 7, somewhere in the application i call a function in a dll using the following :
declare long FunctionName in DLL_NAME.dll string#, string#
.
.
.
RETURN FunctionName( StringParam1, StringParam2)
calling this function generates an error :
The following error has occurred:
Message: Cannot load 32-bit DLL d:\folder\DLL_NAME.dll.
i tried registering the dll using the 32/64 bit regsvr...no luck !
Info that could help identify the problem :
the dll file is not local, it is in a folder in a network mapped drive.
thank you very much for your help.
Aside from VFP not supporting anything 64-bit, I would look at the fact you are trying to load a dll across the network.
Eliminate that as a possible issue and copy it LOCALLY and load it from that...
Try to eliminate everything ELSE, including your VFP application. I would start directly from the VFP command window and do nothing but have a simple .prg file. In it, put nothing but the declaration and reference a LOCAL copy of the dll file. Set the values for your parameters, and then call the function.
If that doesn't work, then it doesn't matter WHERE in the application its being called... you've just eliminated that whole set of conditions and environment.
Its almost like support I offer to clients sometimes when trying to do something in our app that requests data from the internet. I have them manually go to their browser and put in whatever URL our app would be trying to go to. If they can't get to it from the browser, its something from their firewall, IP blocking, or other... it has nothing to do with our app. You might be running into a similar situation. Leave out all other elements and just get the few to absolutely test the problem isolated to itself.
I agree that the issue is likely that the dlls are located on a shared network. I have solved this problem in the past by copying the files to the local machine(s).
However, according to this article (link below), you can allow a FoxPro app (or any .exe for that matter) to use dll's from a networked drive if you add a special config file that tells the .Net framework that it's okay to access networked dlls for a certain app.
Here is the link: http://www.west-wind.com/webconnection/docs/index.htm?page=_36e0qlogr.htm
I'm looking for suggestions on keeping a program that is running on a network updated. Installation consists of 15 users, each have the program on their local pc, but they all access same date from sql server.
I am looking for a clean method that would allow me to update one folder on the network and for each computer to get updated when they run the program and the programs sees a later ver on that folder on the network. (Obviously I can do this inside the program itself since it won't allow being overwritten while opened.)
You should have a look at
ClickOnce is a deployment technology
that enables self-updating
Windows-based applications that can be
installed and run with minimal user
interaction.
Using ClickOnce Deployment in
VB.NET
ClickOnce - A new VB.NET 2005 Deployment Tool
ClickOnce Deployment for Windows Forms Applications
ClickOnce Deployment in .NET Framework 2.0
Another option is to create a second program that will check the network for an updated version of your application. Let's call this program "updater.exe".
You can run updater.exe on system startup like Adobe Reader or Sun Java do.
Or, when your application is started it can load updater.exe. If updater.exe finds an update, it can close/unload your application, download the newer version, restart your application and close itself.
astander's answer above is correct, you can use ClickOnce for this. Another option is creating this application as a web application.
Web applications basically work the way you described, the application's files reside in a web server, all the users connect to it using a browser, and to update the application you only need to update the files in the server.