I've been following the advice in this question.
How to add a WiX custom action that happens only on uninstall (via MSI)?
I have an executable running as a custom action after InstallFinalize which I intend to purge all my files and folders. I was just going to write some standard deletion logic but I'm stuck on the point that Rob Mensching made that the windows installer should handle this incase someone bails midway through an uninstallation.
"create a CustomAction that adds temporary rows to the RemoveFiles table"
I'm looking for some more information on this. I'm not really sure how to achieve this in c++ and my searching hasn't turned up a whole lot.
http://msdn.microsoft.com/en-us/library/windows/desktop/aa371201(v=vs.85).aspx
Thanks
Neil
EDIT: I've marked the answer due to the question being specific about how to add files to the removeFiles table in c++ however I'm inclined to agree that the better solution is to use the RemoveFolderEx functionality in wix even though it is currently in beta (3.6 I think)
Roughly you will have to use the following functions in this order:
MsiDatabaseOpenView - the (input) handle is the one you get inside your custom action functions
MsiCreateRecord - to create a record with the SQL stuff inside
MsiRecord* - set of functions to prepare the record
MsiViewExecute to insert the new record into whatever table you please ...
MsiCloseHandle - with the handle from the very first step and the record handle (from MsiCreateRecord)
Everything is explained in detail over at MSDN. However, pay special attention to the section "Functions Not for Use in Custom Actions".
The documentation of MsiViewExecute also explains how the SQL queries should look. To get a feel for them you may want to use one of the .vbs scripts that are part of the Windows Installer SDK.
If you use WiX to create your installation package, consider using RemoveFolderEx element. It does what you want and you don't have to write the code yourself.
Read Tactical directory nukes for an example of how to use it.
If you still want to implement it yourself, you can get your inspiration from this blog post, there's the code for doing this in VBScript.
Related
I know how to create and code my own setup program but i need to be redirected at some point. This point i'm sure inlight other people too.
I created a setup project. All is done. Except, installation files inside of EXE.
I know 2 different ways of doing this:
Create resource in EXE and embed RAR/ZIP file.
Put compressed archive with files along with EXE. EXE will read contents and data from this protected and compressed ZIP.
But what i want is number 1. I want to embed it. But;
What is the proper way of embedding this? Are other setup creators do the same thing? Embed resource as compressed single zip in EXE? Or do they another trick?
How do you extract files? On the fly by memory? Like read each file one-by-one. Synced. Or first, copy ZIP to temp and extract from it.
Or even embed all files separately to the resources.
I, even think that if i should create simple MSI without dialogs and embed it and run from background but i want to take all control. I want everything belongs to the original setup that i created.
Note:
I want to make my own dialogs, effects, procedures, functions and
steps. Yes, MSI is acceptable but i will stick with its features. Oh,
If im able to extend it, why should i spent more time doing this
instead of making my own? I am so confused... I am talking about very big setup project here. Not just a standard ugly UI with less features. At least, im gonna try :)
Do not give me any sample/code just show me a correct path, please.
Best options here:
Create ZIP compatible EXE that reads itself as ZIP and read the file list and extract.
Create non-zip compatible EXE that has a hidden body somewhere and read that area (seek) and get the list & extract.
The proper way to do it is to use the Windows installer technology, aka MSI. There is a nice, Microsoft blessed toolset called WiX that you can use to greatly simplify the process.
http://wix.codeplex.com/
If you are truly intent on reinventing the wheel, you can look through the source code to WiX on how things are done.
Best options here:
Create ZIP compatible EXE that reads itself as ZIP and read the file list and extract.
Create non-zip compatible EXE that has a hidden body somewhere and read that area (seek) and get the list & extract.
Why write your own? Much easier to use WiX (http://wixtoolset.org/) with optionally a graphical interface like WiXEdit (http://wixedit.sourceforge.net/). Have you thought about additional requirements like uninstall etc...
Good luck!
Would InnoSetup help with your problem? You can personalise the dialogs and extend its functionality quite a lot.
On my workplace we are not allowed to used Sharepoint Designer, but I need to make a list with customized columns but still maintaining the original style and functionality.
My idea was to find a way to export the list XSL, edit it and use the option to use a custom XSL on the web part.
The thing is, I coudln't find a way to get the XSL, I only found ways to export the XML. I need a way to change how the list is displayed in a way someone else other than me can keep the list updated without needing a lot of programming knowledge
That's a tough one. The technical answer is that the .xsl files start at /_layouts/xsl/main.xsl and /_layouts/xsl/local.xsl, which call more files. However, customization of a list or library will be embedded within the aspx page you're using to view it, and the xsl is "by exception" for anything different than the default templates. SPD creates a whole lot of that exception code automatically. You can try to reverse engineer the main, local, and other xsl files, but that's a herculean task. If you have a specific list and a specific goal, you could post your WebPartPages:XsltListViewWebPart code here or in a new question and someone with SPD could make the changes for you.
One alternative, which you might prefer since it'll leave you in control, is to set up your page to be as close to your desired design as you can, then save the aspx file locally. Using a standalone (maybe even personal) computer, install SPD and (if it comes to it) a copy of SharePoint Foundation. Add your aspx file to that, use SPD to make the changes, and copy the file back. Be sure to keep an eye on the list and view guids, since those'll change between the two, but otherwise they should be the same.
I have seen some posts that mention the xmlserializer being called at runtime in .Net.
I have a sharepoint web-part that calls a webservice to retrieve data, and then is supposed to display that data on the web-part. But I get this error:
System.Runtime.InteropServices.ExternalException: Cannot execute a program. The command being executed was "C:\Windows\Microsoft.NET\Framework64\v2.0.50727\csc.exe" /noconfig /fullpaths #"C:\Users\my_deploy_spFarm_user\AppData\Local\Temp\OICE_356C17F3-2ED2-423C-8BBE-CA5C05740FD7.0\eelwfhnn.cmdline
Now the posts I have read here, state that the problem is that the compiler is trying to to create an XML serialization assembly on the fly, but does not have privilege to do so.
I have seen some suggestions to use the post-build events to create this XML Serialization Assembly at Compile-time. However I am not sure of how to do that, and also I am not sure if this assemply would get included in the .wsp package?
I'd take a good look at whether you really want the full, automatically generated serializer, or whether you just want to emit/parse some relatively straightforward XML - if the latter, you'll solve this problem by not using stuff that needs generated code, i.e. use the XmlReader/XmlWriter directly.
This link has the basic command to create the pre-compiled serializers.
Okay SO. I need some guidance. I apologize for the length of this post, but I need to provide some details:
I've got someone who is interested in me to do a small project for them. The application in general is a fairly straightforward employee record keeping / documentation app, but it makes pretty heavy use templated Word and Lotus documents. The idea is you select the employee “event” such as commendation, promotion, discipline, etc., and it loads the appropriate template doc and you fill it in from there, and later you can select an employee, view all the “events,” and view the individual documents associated with each one.
Thus, the app must know where the .docs are saved when the user is done.
The client actually has a v1 of this app (it doesn’t do any management of the files or anything, just launches Word/Lotus with the document you wanted to view in a new instance, presumably via a system() call.) We’ve not gotten into a detailed requirements phase, but the client and I agree that for this to really work, some kind of control over where the user saves the .doc’s to is going to be critical , because otherwise the app provides them with the new copy of the template doc, they "Save as" somewhere else, and the app is pointing to the blank copy it provided them with.
Obviously, I can’t think of a way to achieve “Save as” restriction/control in any way via just launching a new instance of Word. The client has the idea of an embedded Word/Lotus instance in the app with the template doc when you choose one, but I’ve few reservations with that:
I’ve dug around online and I’ve read that whichever version of Word I borrow MSWORD.OLB from will be the one the end user would require?
I’ve tried to do the MSDN example of embedding a Word doc from here, but as I’ve come to get used to, the MSDN example doesn’t even compile.
Even if I CAN figure out how to embed a .doc file into their application, I don’t know that I could control the use of “Save as…”
All of this STILL hasn’t touched on Lotus (!)
So… instinctively, I feel the embedded Word/Lotus thing has to be more work than it’s worth in the end.
So I’ve had a few other ideas brewing around.
One is looking into using Office XML (and if there’s a lotus equivalent), and get the user’s “inputs” separately and generate the document on the fly each time. I’m not particularly thrilled with that idea, but I think it COULD work, provided I just use old features to try and stay far backwards compatible.
Get user’s “inputs” separately and generate a document in HTML. Meh. Works, very cross platform and easily parsed and understood, but not good if you want to be able to email it to someone (who emails a .html? Works, yes, very unconventional which to the average user will throw them off) and even worse if you need to email it to someone for revisions…
Perhaps some kind of editable PDF? I know there are PDF libraries out there, and the more I stew on it, the more this sounds like the best option, though I’ve not done much work with PDFs and I don’t know how easily embeddable they are / what options one has when creating them. I know they can be save-disabled, I’ve had that with my bloody state taxes before.
I need some input here. Here’s the TLDR questions:
Is launching a new instance of Word for each .doc as bad as I feel, given user can “Save as” document wherever and then application is left pointing to a blank document?
Is trying to support embedded Word as big of a trouble as I feel like it is / more work than it’s worth / likely to cause problems with supporting multiple versions of Word? (Forward compatibility as well as currently released versions?)
What are thoughts on the PDF plan?
Any other good ideas?
Word does allow for programming some "Save" and "Save As" control via its object model. Any subroutines coded in VBA and placed into your Word template will be copied into all documents generated from that template. Additionally, most menu and Ribbon commands can be intercepted by creating a module containing subroutines named for the intercepted commands. So, for example, if a module contains a sub named FileSaveAs(), any code in that sub will be executed instead of the standard File|Save As command. Lastly, this code will replace Save As commands executed via keystroke, toolbar, menu, or Ribbon.
The code below will launch a dialog box to a predetermined path whenever a "Save" or "Save As" command is executed:
Sub FileSave()
ControlSaveLocation
End Sub
Sub FileSaveAs()
ControlSaveLocation
End Sub
Sub ControlSaveLocation()
Dim Directory As String
Directory = "C:\Documents\"
With Application.Dialogs(wdDialogFileSaveAs)
.Name = Directory
.Show
End With
End Sub
Hope this helps.
I'm looking for a good efficient method for scanning a directory structure for changed files in Windows XP+. Something like how git does it is exactly what I'm looking for, when running a git status it displays all modified files, all new (untracked) files and deleted files very quickly which is exactly what I would like to do.
I have a basic model up and running which performs an initial scan and stores all filenames, size, dates and attributes.
On a subsequent scan it checks if the size, attributes or date have changed and marks as a changed file.
My issue now comes in detecting moved and deleted files. Is there a tried and tested method for this sort of thing? I'm struggling to come up with a good method.
I should mention that it will eventually use ReadDirectoryChangesW to monitor files and alert the user when something changes so a full scan is really a last resort after the initial scan.
Thanks,
J
EDIT: I think I may have described the problem badly. The issue I'm facing is not so much detecting the changes - I have ReadDirectoryChangesW() using IOCP on multiple threads to detected when a change happens, the issue is more what to do with the information. For example, a moved file is reported as a delete followed by a create and a rename comes in 2 parts, old name, followed by new name. So what I'm asking is how to differentiate between the delete as part of a move and an actual delete. I'm guessing buffering the changes and processing batches would be an option but feels messy.
In native code FileSystemWatcher is replaced by ReadDirectoryChangesW. Using this properly is not simple, there is a good baseline to build off here.
I have used this code in a previous job and it worked pretty well. The Win32 API itself (and FileSystemWatcher) are prone to problems that are described in the docs and also discussed in various places online, but impact of those will depending on your use cases.
EDIT: the exact change is indicated in the FILE_NOTIFY_INFORMATION structure that you get back - adds, removals, rename data including old and new name.
I voted Liviu M. up. However, another option if you don't want to use the .NET framework for some reason, would be to use the basic Win32 API call FindFirstChangeNotification.
You can use USN journaling if you are up to it, that is pretty low level (NTFS level) stuff.
Here you can find detailed information and source code included. It is written in C# but most of it is PInvoking C/C++ functions.