If we give set up to the user then there is a possibility of coming changes in the code for the set up we had given to the user then we have to make set up again and then we will have to give the set up to the user, then it is not problem but user has to uninstall that set up and has to install new set up again, that is the problem then is there any other option to that ?
I am asking this question because in a application there is a chance to come changes in only one dll of the application then is there is any other option that we make the changes in that dll and give to the user and user has to update only that dll and not has to uninstall whole setup and reinstall whole setup ?
.net dlls don't need to be registered so why dont you make a small update program that would simply replace the updated dll. No need to uninstall and reinstall.
If I understand your question correctly, you are asking for a better deployment solution
for .NET based applications?
In that case I suggest you take a look at ClickOnce.
Visual Studio has ClickOnce support out of the box.
Basicaly you deploy the applications through some medium, for example via the internet,
and whenever you push a new update the customer will have the option of upgrading automatically, of you can even have your software update in the background.
If you do not want to use ClickOnce, the other option is to use MEF.
This will allow you to extend your application with so called add-ons.
These add-ons are basically classes that are loaded from assemblies at runtime.This means you could have a running application using version 1.0 of a certain assembly and even while the application is running the user could replace an assembly and the software would be up to date.
So either you use clickonce to update the entire app automatically,
or you break your application up into smaller parts, load those parts using MEF and have an installer that simply replaces parts on the target system.
When we run our application a log in window appears where a valid user have to provide his credentials to get in (Old stuff!). As they put them in and after successful sign up we fire up a web service request sending the client application meta (version, operating system, etc.). That web service is hosted on our domain. That web service struck to a default function where it query to database to get the information of the latest (or stable) release of the system and then we compare it with the information we got from a client application and send back the comparison. The receive data is a bit value which fall into a case of message window like if this is an older version client application pop up a window allow to download the newer version of the application (or the newer version is available but not compatible with your operating system etc)
We do few more stuff on successful sign up (like License Key Verification). Why after successful sign up 'cause only valid user have the right to stuck our web service
Related
I have desktop application that can be installed on the users computer with "setup" msi file like any other application.
I'm developing web application and I need somehow to integrate the desktop application with the web application. Web application is developed using PHP (desktop application is developed using C#), and when clicking on one button on the web application, the desktop application needs to be launched.
Is there a way of doing this? I was thinking about a few scenarios:
-Maybe if possible to install the app directly on the server and to launch it from there?
-Maybe to be required the user to have the app installed on his computer and to call the app from there?
If possible I would prefer to not use the second approach because it's better if the third party to not be involved - it will be more user friendly if the application is launched directly. But any help will be appreciated because at this point I'm not sure if that is possible to be done at all.
You can install app at server an run it with exec() or "`" operator - but to control gui of app you need to use some like autoit ant etc.
If you ultimately decide to require your users to have the client application installed and expect majority of the users to be on Windows, you could register your application to handle specific scheme and parse its command line when started. More on this here:
http://msdn.microsoft.com/en-us/library/aa767914(v=vs.85).aspx
You'd register a custom scheme and then intercept in in the application's command line arguments. The whole URL will be passed as an argument, e.g.:
myapp://parameter1,parameter2
The browser will mostly ask whether or not the user trusts the application to handle this scheme with an option to remember this setting.
If you don't have access to the source code of the client application, you can develop a middleware, some sort of a launcher that handles the URL and then runs the client application after maybe modifying some configuration files based on the URL or otherwise controlling the third-party application to do as you with.
As for solution #1, I don't think C# matters if your application can run on Mono, so you should be able to just run it from PHP. However, this probably won't work on web hosting and you will have to get a VPS for that.
There are very good (security) reasons why it is hard to launch client-side processes from web browsers.
Do you have access to the source code of the C# app? If so, you could consider modifying it to take advantage of Microsoft ClickOnce deployment.
Some references:
http://msdn.microsoft.com/en-us/library/t71a733d.aspx
http://msdn.microsoft.com/en-us/library/t71a733d(v=vs.80).aspx
http://msdn.microsoft.com/en-us/library/6ae39a7c.aspx
http://www.codemag.com/Article/0902031
Here's an old article on deploying WinForms applications via ClickOnce with Visual Studio 2005: http://msdn.microsoft.com/en-us/library/ms953320.aspx
It can possibly be done with IIS but it can be cumbersome setting it up to run as the current user, especially since it would probably also need to run elevated for an app that needs to attach to the current user's desktop.
Easiest is to install a Windows LAMP distro (like WAMP: http://www.wampserver.com/en/) and then run the httpd.exe directly from an elevated (Admin) command prompt; do not run apache as a service!
Once you do this performing and exec("command"); call in php will bring up a desktop app as if it was invoked from an admin command prompt. Obviously you need to set up the apache server to be accessible from outside the local system, etc.
I currently have an in house C# app that is delivered via click-once. I'm moving to the cloud and would like to have the Click-Once delivered from there (will be accessed from multiple countries and I can't use IP ranges to block out intruders), but it appears that the only way to secure the download is using windows security which is not an option for my clients.
I'm looking for a nice way to deliver the initial software and then keep the clients updated.
I've heard about WIX but I can't seem to find any information around updates from the internet and it.
Does WIX support this? If so can someone point me at an example or reference?
If it doesn't support it is there another solution someone can recommend?
Here is my usage scenario:
- User logs into a website supplying credentials, (username/password or certificate) then has the ability to download and install the application.
The application must check on startup of the app for a new version and if there is automatically download, install then run it. (would be nice if the user must resupply credentials for the update but not a necessity)
Bonus points if it will work on any web server such as a simple Node.js implementation.
WiX Only handles the installation via the bootstrapper or MSI you have generated, so I would assume that it's most likely a windows installer setting of some kind when it is first created. The element ClickThrough is supposed to be able to handle this scenario, though I don't know much about that.
The way my work colleagues dealt with this is by using IIS and an ASP.NET web service, along with a DLL that has methods to check with the web service if there is an update, and then prompts the user about the update and asks if they wish to update (did I say update enough in that sentence?).
Hope this helps.
I need to enable a .NET application to run over a network share, the problem is that this will be on clients' network shares and so the path will not be identical.
I've had a quick look at ClickOnce and the publish options in Visual Studio 2008 but it needs a specific network share location - and I'm assuming this location is stored somewhere when it does its thing.
At the moment the job is being done with an old VB6 application and so gets around all these security issues, but that application is poorly written and almost impossible to maintain so it really needs to go.
Is it possible for the domain controller to be set up to allow this specific .NET application to execute? Any other options would be welcomed as I want to get this little application is very business critical.
I ought to say that the client networks are schools, and thus are often quite locked down as are the client machines, so manually adding exceptions to each client machine is a big no no.
Apologies, I forgot to mention we're restricted to .NET 2.0 for the moment, we are planning to upgrade this to 4.0 but that won't happen immediately.
The deployment location in the manifest must match the location where it is deployed. You are going to HAVE to use a UNC path. There shouldn't be any problem with this. ClickOnce applications install under the user's profile, and require no administrative privileges. It only needs read access to the file share where the application is deployed.
The best answer is to create deployments for each school and for you to set the UNC path, because then you can just send them a signed deployment and they can put it on the file share. But that's a major p.i.t.a. if there are a lot of schools involved.
The next answer is: Who actually deploys the application to each school, i.e. puts it on the file share? Is there some kind of administrator?
What I would recommend (depending on who it is) is giving them mageUI.exe and teaching them how to change the deployment URL and re-sign the manifest (it will prompt). The problem with them re-signing the deployment is they have to have a certificate. You could give each school their own certificate (created with the "create test certificate" button in VS, or use MakeCert to create one [ask if you want more info]) or give them all the same key (not very secure, but hey, it would work).
If you at least updated to .NET 3.5 SP-1, you could deploy the application without signing it. (I'm not giving you a hard time about .NET 2.0, my company is in the same position, I'm just passing this information on.)
If the computers have internet access, you could probably find somewhere to host the deployment for $10/month, and push it to a webserver and let them all install from there. Then everyone would get updates at the same time, you would only have to deploy updates to one location. This would be the simpliest solution, assuming they have internet access.
RobinDotNet
Visit my ClickOnce blog!
On the "Publish" tab of your project properties there is a "Installation Folder Url" textbox. Visual Studio requires you to put something there. Just put in any random UNC path (\\someserver\randomfolder)
Click the "Options" button. Select "Manifests" and check "Exclude deployment provider URL". This will remove the path you were forced to add in step 1.
This should allow clients to put your deployment wherever they want. When their users install, their start menu shortcut will point back to where they put the deployment.
Here's the description from MSDN about that checkbox...
Exclude deployment provider URL
Specifies whether to exclude the
deployment provider URL from the
deployment manifest. Starting in
Visual Studio 2008 SP1, the deployment
provider URL can be excluded from the
manifest for scenarios in which
application updates should come from a
location unknown at the time of the
initial publication. After the
application is published, updates will
be checked from wherever the
application is installed from.
Perhaps, the link here could save you, if I am not mistaken, you are worried about the drive letter and handling UNC conventions? Take a look at this on CodeGuru, which contains code on how to map to a UNC share dynamically at run-time.
The problem is Security related to the .Net framework. Unfortunately i don't have much experience in this area, but maybe one of these links will help:
Microsoft is aware of this problem
Hint about mscorcfg.msc
Another hint from ID Automation
Last but not least: A google search
Can you use a UNC path?
\\\server\folder\app.exe?
I've been writing desktop apps in C# for some time now but I'm increasingly getting frustrated with the fact that not everyone has .NET 2 or Higher installed. I don't have the option of upgrading their systems to meet my needs. My apps are mostly utilities that run alongside the main program the company I work for has. They access the file system and the registry. Being relatively new to programming in general, I was wondering if moving these tools to the web would solve some of my problems. But I have no idea if web apps can have access to these parts of Windows. I was thinking of writing these web apps in either Rails or ASP.NET. So my question is this. Can a web app access and modify the registry and file system of Windows?
Thanks.
Nope, "web apps" like asp.net or rails apps run on the server alone and just serve html to the client. So all the client-side code can do is what jscript running in the browser sandbox can do, ie no file access or registry access.
You can however install an activex on the client computer that gets full access, but the user has to agree to install it as it's a security risk.
Writing the apps as Web apps instead (and Rails is cool to use) is a good option - your users don't need to install anything, upgrades are easy to do, and dependancies are no longer a problem.
However, you now need to start re-architecting your apps so they do not need to write anything to the client, except a cookie (that's stored in the browser). If you can do this, then migrating to a webapp will be great.
If you cannot, my advice is to learn the same language that your company's app is written in. Once you do that, the company app will have taken care of the dependencies already and you will just need to offer your utilities alongside the app, perhaps even in the installer, or just to copy the files into a subdirectory. If you're thinking of learning Ruby, then learning the corporate language will be just as difficult (only you'll be able to reuse a lot of code used in the main app)
No, a traditional asp.net application cannot access the file system or registry on the windows box. Simply put because it doesn't actually run on the client machine. Instead it runs on the server where it does not have access to the local machine.
It is possible to have portions of the application which run on the client machine. Browser based applications for instance. However these would require that the 2.0 framework be installed on the customers machine which puts you right back at square #1.
No, this isn't possible. Web applications cannot modify the registry and/or file system on a user's machine because of the security implications. You would need to develop a Windows app to do these kind of changes. You could always make this tool available for download on your website though.
No, you can't do that with a web application. Besides others have already said, a web application run in a browser, not inside an operating system, so all you can do is what browsers allows you to do and not all you want, and browsers doesn't allows you to take control of the host machine.
I'm guessing the desktop app used in your company uses the registry to store workstation / user specific (state)data.
Moving to a web based app does not mean storing state data is no longer possible, just account for it by including a table in your database that can be used to save that same (state)data in. The registry is no longer needed.
Another pro is that by moving to a fully webbased application, you never have to worry about your endusers, because the code is running on the server, all the enduser gets is the output in html :-D.
The only thing to keep in mind is cross browser compatibility, don't create an app that works in IE only for instance, it has to look and work the same in all major browsers.
There are a few products out there, such as Xenocode and VMWare's ThinApp, that allow you to virtualize your app's dependencies to the point where your .NET app can run on a machine without the .NET Framework installed. Just another option from left field.
Specifically, this is for a .NET 2.0 desktop application. Currently we require the user to manually go through the update process via our website.
What are the best ways of doing a silent or automatic upgrade of the client behind the scenes?
Thanks!
I would suggest a read of chapter 4 of Microsoft's .NET Applications Lifecycle Guide. The one I would promote is hooking up an Automatic Update system - you can write a small system to contact a web server that you own, check if there is an upgrade available, download and install the upgrade patch.
You may take a look at ClickOnce or Updater Application Block.
I'm not a big fan of ClickOnce. I like the concept, but not the specific implementation.
The way I have done an application update system in the past is to zip all the application's files into a container file and put it on my web server. To make things easier, I automated the creation of the container file. On the web server, I have a version info file that lists the current version and the container's url like this: 1.0.0.0|http://www.example.com/path/to/container.file. To parse the version info file, all the application needs to do is split the file contents using the pipe character '|'. The first array element will be the version number and the second element will be the container file path.
On startup and at an regular interval such as every 2 days (just in case the user leaves the application running for an extended period of time), I have the application check the version info file on the web server and determine if the version listed there comes after the running version. If there is an update, the application prompts the user. If the user wants the update, the application downloads the container from the url specified in the version info file and saves the contents in the application's folder, renaming the currently running exe to xxx.exe.old to allow the new exe to be saved as xxx.exe. Then the application restarts itself and the new exe deletes xxx.exe.old.
When you want to publish a new version of your application, all you need to do is increment the version number of your application, update the version info file with the new version number, and upload an updated container file to your web server.
I would rather not have an application doing silent updates without my knowledge.
In fact, I would prefer to be told that an update is required, a silent update would be perceived to be malicious, hiding something from the user and taking over the machine without my consent. What would happen if the silent update screwed up the machine without having knowledge of why the machine 'appears broken' due to a screwed up registry etc...
Yes it is debatable...
My 2cents