I am writing a C# console application which collects data about a machine and writes it to an external database. One of the bits of information it is necessary to collect is information about the software that is installed. There is a set of specific pieces of software we have that we would like to know about. Specifically which ones are installed, which versions are installed, and which patches they have had applied.
I have managed to acquire the information about which software is installed, and which versions they are, by querying the registry. However, when it comes to figuring out which patches are installed I am a little stumped.
I know that if I go to Control Panel -> Programs -> View installed updates I can see the patches I have installed for these software (specifically, it gives me the exact patch number - ie, Patch 21). So, I would like something similar. I found WUApiLib and thought it would be the answer to my problems, but when I query the update history all that is returned is a list of Microsoft updates to the OS, .NET, Visual Studio etc. There is no mention of the patches I applied to our software.
I am not very familiar with how patching works, but I believe the patches use msp file format, so I think the information should be logged by Windows somewhere. How does Control Panel get it? Where might I be able to get it? The registry entries under HKLM/SOFTWARE/Microsoft/Windows/CurrentVersion/Uninstall do not mention patches at all.
So, after some digging around I found a different part of the registry which lists all the information I needed.
HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Products
This contains the name and version of software installed (under <GUID>\InstallProperties) and patches installed for each (under <GUID>\Patches)
Related
How Can a Web Page Display What Version a File is In Program Files Directory?
For example, if I wanted to send a user a URL that would show the user what version of our software is installed (version number and release date) on their Windows PC. I'm just talking about file properties, not actually running something.
Is there a way to do this with .Net/ASP.Net?
The answer is no.
The best you can do with HTML5 or Javascript is to let the user select a file and even then you have very limited access to properties (at most name, size and type) without having the user upload the file.
The most efficient solution right now would be to serve a very basic clickonce application which would locate the files, read the properties and send the information back to the server. From there you can choose to redirect the user back to your website with the information you collected.
Generally access to the Programm folder is limited at best. There used to be a time when we even would write data like Configuration files there. That was Windows 95/98. And it was frowned upon back then.
With the introduction of NTFS with Windows NT (and later XP in the Consumer area), enforceable rules were put in place. Rights tend to be highly limited. This is even more true of Webservers, as they tend to be prime targets for hacking. The only rights you can expected a Webserver to have is read rights to it's programm and the content directory. Maybe if the admin is really nice and it really helps with performance, it might have write rights on a Temporary subfolder of Contents.
Reading out your version from a file is propably possible with only read rights, but not the right way. Usually you just let the compiler hardcode (insert as constant) whatever Version is given in the Project file or by the Version Tracking Software.
So the first thing is that you need some approach of Version Control. And then your answer depends "however this Version control mechanism does tracking of the Compiled version". There is some limited version tracking support in Visual Studio itself. But there is also full, 3rd party Version tracking Software.
I know this question has been asked lots of times but mostly I couldnt find the answer I was looking for.
How do popular applications update themselfs ?
I found some libraries that update applications but mostly they just replace all the application files. This way my Updater would need to download around 200mb everytime.
Also ClickOnce is used a lot but this in my oppinion is an ugly way to update and install because the GUI is not really fancy and you can't even specify where to install the application.
I know some applications also replace the installer and just run the new one to deinstall the old version and install the new one but that cant be that right way...
So how do Programs like Mobirise, Discord or Teamspeak update themselfs ?
I have a have made a POS Solution(C#), working in 4 Shops.
This is what i've done to give client side updates.
Used Google Drive to upload installer file + a text file mentioning installer version, once uploaded each time the programe starts up it downloads the version text file from Google Drive, if it doesn't match the current version of the software which the clients Has, Messagebox Prompts a newer version is avaliable. Client then can click Upgrade and it will download the installer file, once downloaded software exits completely calling a python script which will Run the installer file.
This is not the best way but it works, becouse Google Drive has its own file version history which makes it easy for me to keep track of updates i send.
Hope I Helped <3
You can design the application to be patchable.
Patching is not a hot flavour in windows world.
I have code in a Provider-Hosted App for SharePoint which calls the OleDBDataReader class in order to parse a .xslx file. In my development environment, the following exception appeared until I installed this driver.
The 'Microsoft.ACE.OLEDB.12.0' provider is not registered on the local machine. I have moved to pre-production, and the error has popped up again even though the admins of the IIS box are swearing back and forth that the driver is installed. They've sent me a screenshot of the install, and it looks like it's the same version I have. They refuse to uninstall and reinstall it since another application is apparently relying on it at the moment. Is there anything else that I can do on my end other than rewrite the code to look at some way of parsing the .xslx file using its stream instead?
I have read through many of the other topics about this, and I can't seem to find anyone doing something differently.
This thread seems to be about a similar error(granted it's for Access database), but the solution may be able to help with your problem:
In that thread the OP also installed the drivers you've linked ,that also failed so s/he installed these drivers:
http://www.microsoft.com/download/en/confirmation.aspx?id=23734
which worked apparently , try that.
I did a quick search on MSDN and the alternative download for your issue is the Office System Driver: Data Connectivity Components
The solution was for the engineering team to complete "repair" on the installation from add/remove programs.. This took forever to have them try, but it worked!
I'm currently searching for a way to make it possible to deploy and update a C# .NET application over SFTP. Background is that most of my users do not have admin rights, internet access rights or common file structures/group policies. The best I could actually get was the ability to also use the SFTP-infrastructure the application already uses for data transfers.
So I tried using Visual Studio publish, which can deploy the application initially, however it does not support the update mechanisms (it only supports URLs and File Paths). A manual update/deployment process is out of the question, however, purely through the sheer size of the userbase (1000+ users).
I then had a look at wyBuild, a third-party build-tool that can actually use sftp to upload Updates. It can not, however, download them via sftp.
So I'm reaching somewhat the end of my rope here. Writing an updater myself seems like a large time investment, but I could not find any other solution. How would this problem be solvable? Thanks for any help in advance.
Oh, and before somebody flags for "asking for a tutorial", I tried hard to stay within the guidelines stackoverflow provides here
One of my favorite things about owning a USB flash storage device is hauling around a bunch of useful tools with me. I'd like to write some tools, and make them work well in this kind of environment. I know C# best, and I'm productive in it, so I could get a windows forms application up in no time that way.
But what considerations should I account for in making a portable app? A few I can think of, but don't know answers to:
1) Language portability - Ok, I know that any machine I use it on will require a .NET runtime be installed. But as I only use a few windows machines regularly, this shouldn't be a problem. I could use another language to code it, but then I lose out on productivity especially in regards to an easy forms designer. Are there any other problems with running a .NET app from a flash drive?
2) Read/Write Cycles - In C#, how do I make sure that my application isn't writing unnecessarily to the drive? Do I always have control of writes, or are there any "hidden writes" that I need to account for?
3) Open question: are there any other issues relating to portable applications I should be aware of, or perhaps suggestions to other languages with good IDEs that would get me a similar level of productivity but better portability?
1) There shouldn't be any problems
running a .NET app from a flash
drive.
2) You should have control of
most writes. Be sure you write to
temp or some other location on the
hard drive, and not on the flash
drive. But write-cycles shouldn't be
a problem - even with moderate to heavy
usage most flashdrives have a life
time of years.
3) Just treat it
like's it any app that has xcopy
style deployment and try to account
for your app gracefully failing if
some dependency is not on the box.
If you want to use com objects, use reg-free com and include the com objects with your program.
You should always have control of your writes. Applications should be loaded into RAM at startup, and then memory past that is allocated in RAM, so nothing is written to the flash drive.
The most important thing for a portable application is that basically no installation is necessary for your application. You do not want to be dependant on registry values especially, since your application will not be 'installed' on other computers.
One of the issues with portable applications you may consider is data persistence. Generally, you write to a user's Application Data folder to save data. If this is the case, any data saved will only apply to the user on that computer. If you want some local application data, you may wish to create a Seralized XML file for your settings and store it locally within your application's directory. This file writing would then likely be the only write actions you'd need to worry about.
For your .NET portability issue, you could also write a small entry program in C++, which checks if the computer has .NET installed. .NET has registry values you can check to see the versions installed, so if .NET is installed, run your application, else display a message stating that .NET needs to be installed first.
Edit: I'd like to add that I do application development for Ultrasound machines using XAML in C# 3.0. The application I write works perfectly from a USB Flash Drive, while all user settings are stored on a local AppData basis, so nothing is written to the USB. While the application can be installed through an .exe installer, the installer does not write any registry values the application depends on.
I don't really have answers for #1 or #3. But for #2, the .NET CLR shouldn't be writing to an app's "installation" folder (i.e. the flash drive) unless your code specifically tells it to or is using and modifying file-based settings (ini, xml, etc) that live with the app.
Number 1 is really the kicker if you're not just writing things for personal use. Obviously hosting a portable copy of the full CLR on the thumb drive is impossible. But there are tools that can scan your assembly for its dependencies and package them up into a standalone .exe so that the CLR doesn't necessarily need to be installed on the target system.
I don't actually have any experience with this so it might be best to take what I say with a pinch of salt. But here is my take on it:
You don't need to do anything special.
It is not really a consideration of an application developer as to how and when writes are made to a drive, that is something that is far better controlled by the OS. I know that Windows caches writes to USB drives so I would trust it do handle that.
The only thing you need to consider is that your application will not be installed. So you need to make sure that you design it to run entirely self contained within the directory it is deployed to. You could optionally also make some writes to the users home directory but this needs to be done through the appropriate environment variables.
I would get writing and see if there is anything special about a flash drive that the OS doesn't handle.