vb.net - How to make a "hub" or a main menu of multiple exe projects that will update independently? - vb.net

I have approx 22 vb.net windows form based projects that are run by different users throughout my company. I publish them using one-click to a network server, then install on each user computer using the set-up file on that server. That way, when I publish an update, it is automatically pushed to each user when they open their programs.
I'd like to consolidate all of this into 1 program. So for example, the Accounting dept, IT Dept, and Customer Service Dept would all have the same icon/program to open, and they choose which program specific to them to open from that main menu. The goal is to remove all 22 programs from user computers and only have 1 installed that runs each individually (somehow).
My dilemma is program updates. When I update a program for the Accounting Dept, IT doesn't need that update. But since it would be only 1 installation and 1 publish, every user on the network would receive updates not relevant to them. So how do I create one main program "hub" for all users that only receives updates to the programs that they need?

You can launch the click once programmatically
Dim url = "\\Software\Production\ClickOnceApp\ClickOnceApp.application"
Process.Start("rundll32.exe", "dfshim.dll,ShOpenVerbApplication " & url)
Just point to the url on your server, where it's installed from. This will launch the app the same way windows does, so it would check for updates when it's run as if it's run from the start menu.
Then you could maintain a list of 22 applications' names and locations in the 23rd app's settings, xml, sql, etc., and add user groups, permissions, etc.
It could be a winforms app which provides buttons according to the configuration above for launching all these apps. Yes, I think this is actually a pretty neat idea.

Related

Can't run different vb.net applications based on the same original app

I have a desktop Windows Forms application I built.
As we try out improvements to the program, I make the changes on a test version of the application, which connects to a test copy of the Microsoft SQL database on the back end.
Basically, to start out, I just copied the program to a different directory, re-named the assembly, created a different PublicTokenKey and used that.
The problem is when I try to run a the test copy and the live copy at the same time. It pretty clearly thinks they are the same program (when I click on the second one, the "busy" circle simple turns for a second, then the already-opened icon in the taksbar gets highlighted), even though they show up in the Task Manager as differently named applications.
What do I need to tweak in Visual Studio so Windows 10 will recognize them as different, separate programs?

MS- Acess database interface update from local

I am extremely new to Ms-Access. I have a central back end access database in server computer. And all the users have the front end user interface installed on their system.
Now, whenever I make any changes to the interface in my local, i need to re-install the updated interface on each of their system. Is their any way that i can do so that i will make the changes only on my local and it will be automatically reflected on all the users' systems.
Thank you.
Ok there are a couple of options that you can do to either fully or paritally automate this process.
Partial Automation
If you don't have a lot of users and you don't want to do a great deal of coding you can write a simple batchfile or vbs file which you set up on the users desktop as an icon. Batch file code would show the following type of information.
#Echo Off
REM Copy your file from server location to local user machine
xcopy "F:\ServerDirectory\databasename.mdb" "C:\ClientDirectory\databasename.mdb" /E /Y /R
Set this up on the users machine as an icon and whenever you want them to update their front end ask them to double click the icon. This will overwrite their client with whatever you place in the location on the server. It is advisable to create all table links to the database back end having UNC paths as well.
I have used this successfully for various applications - I make changes to the front end place in appropriate location on the server and then do a quick e-mail to people just to ask them to double click the bat file icon.
Full Automation
Programmatically set version control up using visual basic so the client checks version number of the client against a server number and if the client is not the latest will download a new version.
This is more involved and full instructions are available here.
Front End Auto Update
When you deploy an MS Access solutions like this, you need to decide whether to share the client MDB file between all users, or distribute copies to each user. It sounds like you have taken the second option. Each choice has merits and disadvantages. If you stay with the current approach, you might look at a scripting option to deploy updated client MDB files between users.

Many user using one program (.exe) that includes datasets

I created a time recording program in vb.net with a sql-server as backend. User can send there time entries into the database (i used typed datasets functionality) and send different queries to get overviews over there working time.
My plan was to put that exe in a folder in our network and let the user make a link on their desktops. Every user writes into the same table but can only see his own entries so there is no possibility that two user manipulate the same dataset.
During my research i found a warning that "write contentions between the different users" can be occur. Is that so in my case?
Has anyone experience with "many user using the same exe" and where that is using datasets and could give me an advice whether it is working or what i should do instead?
SQL Server will handle all of your multi-user DB access concerns.
Multiple users accessing the same exe from a network location can work but it's kind of a hack. Let's say you wanted to update that exe with a few bug fixes. You would have to ensure that all users close the application before you could release the update. To answer you question though, the application will be isolated to each user running it. You won't have any contention issues when it comes to CRUD operations on the database due to the network deployment.
You might consider something other than a copy/paste style publishing of your application. Visual Studio has a few simple tools you can use to publish your application to a central location using ClickOnce deployment.
http://msdn.microsoft.com/en-us/library/31kztyey(v=vs.110).aspx
My solution was to add a simple shutdown-timer in the form, which alerts users to saving their data before the program close att 4 AM.
If i need to upgrade, i just replace the .exe on the network.
Ugly and dirty, yes... but worked like a charm for the past 2 years.
good luck!

Write permission for user who installed msi package

first of all, i'm not an expert programmer by any means so please excuse if my lingo is off.
I programmed a small project for school, basically it's just a simple cash register application. The user can select products to sell, create new products etc.
When selling products, the user has the option to "print" a bill, ie the program fills a string with some information and creates a new textfile via streamwriter. Also, once the program gets closed, the current stock of products gets saved in a serialized file. The same file gets loaded every time the program starts.
Everything worked fine during debugging, however I created an msi package to test it and neither saving the textfile nor the serialized file works because apparently I don't have sufficient permission to do so.
Can someone tell me how to give the user who installed the programm with the msi the rights needed to make my program work?
I assume you are running on Vista or newer OS? This is the case where UAC prevents your normal applications to write to Programs Files (where again I assume you have installed the application).
The recommended locations to save user data are mentioned in this StackOverflow thread:
Best place to save user information for Windows XP and Vista applications
You can also set permissions in the package during the installation using MsiLocakPermissions table, but I would not recommend it. Program Files folder should be used to store application resources, not user data.

Synchronize 2 SharePoint Libraries on Different Servers

I need to copy or synchronize 2 libraries between 2 different servers. Here are more details:
1- I have an InfoPath form that is submitted to a document library, Lib #1.
2- The InfoPath form is published as a content type and Lib #1 is configured to deal with this content type.
3- The users will have the ability to add new items to Lib #1.
4- At the end of each day, or may be every hour or so, I need to copy the newly created items or sync Lib #1 with another library on a different server.
5- The content type will be available in both servers.
I am new to SharePoint so I appreciate if you can show me some hints on how to achieve that.
Clarification
I don't know which route to take, I am thinking of utilizing any of these (if possible):
1- Replicating Database: Use replication to copy data from one SharePoint database to the other
2- File System: I am not sure if the forms are saved in file system but if they are, I could copy the forms from one server to another.
3- Programatically: I am reading about SharePoint server events. I can program against the List Item Added event and try to copy the item from one server to anther.
4- Built in: May be there is a built in tool that I am not aware of that can help me copy items.
Why do you want to do that ? If the target is entirely different server, forms won't open from there unless you relink the documents and you have same form template deployed on that server.
To do this job, you have two options:
Realtime - Use ItemAdded event handler, to copy the item to target as soon as it is created.
Timer Job - You can create a timer job which will run as per some schedule and copy the items from one library to other.
Reject the DB and file system approach. Accessing DB directly is not supported. And these are not stored on filesystems. SharePoint API is only way. You can use either in Event handler or timer job.