How to use the "KeepRevisionForever" property to keep all file versions - c#

I've recently loaded documents into Drive in C#, but was not aware of the KeepRevisionForever property. Now that I'm trying to upload newer versions of the documents, I'm trying to set this property to true, but it looks like it will only keep this property for the latest update. I.e., I'll upload up to version 5, but the KeepRevisionForever property is only set for version 4, not versions 1 - 3. Can the API allow for keeping revisions for all updates?
Below is the code block where this is being done:
Google.Apis.Drive.v3.Data.File fileUpdate = new Google.Apis.Drive.v3.Data.File
{
Name = doc.Name + "." + doc.ApplicationExtension
, ModifiedTime = doc.DateModified.ToUniversalTime()
};
var update = aobjservice.Files.Update(fileUpdate, doc.GoogleObjectId, docUploadStream, doc.mimetype);
update.KeepRevisionForever = true;
update.Fields = "*";
var task = update.Upload();
UPDATE: I'm up to 34 previous versions of this file, plus the current version (35), and I'm noticing that the older ones get this property checked. And if I keep updating this file, it'll keep updating this property for the file that's 3 versions prior to the current. Below are the version numbers and whether the "Keep revision forever" is checked for that version:
Yes
No
No
No
Yes

According to Manage Revisions, just set the keepRevisionForever to true if you don't want Drive API to auto-purge old revisions:
Google Drive automatically purges (or "prunes") older revisions in
order to optimize disk usage. To prevent this from happening, you can
set the boolean flag keepRevisionForever to true to mark revisions
that you don't want Drive to purge.

Related

Property of an AppModel application not getting updated in SCCM

I'm trying to update SDMPackageXML property of an AppModel application through C# code. SDMPackageXML is an XML property. I've to update only one node named AutoInstall in the
SDMPackageXML XML property. Here is my code:
ObjectGetOptions opt = new ObjectGetOptions(null, System.TimeSpan.MaxValue, true);
var path = new ManagementPath("SMS_Application.CI_ID=16777568");
ManagementObject obj = new ManagementObject(scope, path, opt);
obj.Get();
foreach (PropertyData property in obj.Properties)
{
if (property.Name == "SDMPackageXML")
{
//change the property value. Set AutoInstall to true
XmlDocument xml = new XmlDocument();
xml.LoadXml(property.Value.ToString());
var autoInstallTag = xml.GetElementsByTagName("AutoInstall");
autoInstallTag[0].InnerText = "false";
property.Value = xml.OuterXml;
}
}
obj.Put();
The problem is that obj.Put(); updates nothing on the SCCM server. Can someone help me please?
So similar to what I talked about in this answer the main problem here is that Microsoft uses a special method to serialize their XML. The deserialization still works with using the default classes but to serialize again there is no documentation as to how to (I'm pretty sure it is possible but I am not knowledgeable enough to do it)
Instead of documentation they provide wrapper classes for this which are shipped with the SCCM Console (Located in the bin directory of the Installation folder of the Console).
In this case this would be Microsoft.ConfigurationManagement.ApplicationManagement.dll. Unlike in powershell where the dependencies in the same path seem to be loaded as well you seem also to have to reference at least Microsoft.ConfigurationManagement.ApplicationManagement.TaskSequenceInstaller.dll as well.
There are also further dlls with names like Microsoft.ConfigurationManagement.ApplicationManagement.MsiInstaller.dll present however at least in my tests the two above were the only ones needed, but if you notice the deserialization failing with "InvalidPropertyException" errors you might need the dll matching your specific application type.
With those two dlls referenced you can write something like this (note I deserialized using the dll as well because why not if it is already loaded and it creates a nice application object to directly modify the properties. This is however technically not necessary. You could deserialize like in your example and only use the serialization part.
ManagementObject obj = new ManagementObject(#"\\<siteserver>\root\SMS\site_<sitecode>:SMS_Application.CI_ID=<id>");
Microsoft.ConfigurationManagement.ApplicationManagement.Application app = Microsoft.ConfigurationManagement.ApplicationManagement.Serialization.SccmSerializer.DeserializeFromString(obj["SDMPackageXML"].ToString(), true);
app.AutoInstall = true;
obj["SDMPackageXML"] = Microsoft.ConfigurationManagement.ApplicationManagement.Serialization.SccmSerializer.SerializeToString(app, true);
obj.Put();
Now one thing to keep in mind is that is can be a little tricky referencing the applications by their CI_ID because if you update the application the id for the currently valid version of the app changes (the old id still can be used to reference the older revision). So if you change the application gotten using the ID and then change it back with the same ID it will look like only the first change worked. I don't know if this is problematic for you (If you just get all IDs then change every application only once it should not matter) but if it does you can search for the application using their name plus isLatest = 'true' in the WQL query to always get the current one.

Sharepoint new file upload version saved as Minor rather than Major version

I have the below setting checked on Sharepoint sandbox account.
Create major and minor (draft) versions
Example: 1.0, 1.1, 1.2, 2.0
Whenever I am trying to upload a new file with some metadata properties the version is setting to 0.1 (Minor Version).
Is there any way i can get this first time upload to 1.0 (Major Version) in sharepoint.
var uploadFile = folder.Files.Add(fileInfo);
// Update item properties
var item = uploadFile.ListItemAllFields;
item.ValidateUpdateListItem(itemMetadata, true, "abc");
context.Load(uploadFile);
context.ExecuteQueryWithIncrementalRetry();
Also the checkin comments don't get displayed for the first time unless it is a major version.
// your code
uploadFile.Publish("Comments for this version...");
uploadFile.Update();
context.ExecuteQueryWithIncrementalRetry();

What are the breaking changes migrating NEST from 1.7 to 2.0?

Is this change of the DateFormat to Format correct?
[ElasticProperty(DocValues = true, DateFormat = "epoch_millis")]
->
[Nest.Date(DocValues = true, Format = "epoch_millis")]
Document path is now a required parameter of update. What is document path is this change equivalent assuming there was not document path setting the updateSelector?
elasticWriteClient.Update<T>(updateSelector);
->
elasticWriteClient.Update<T>("", updateSelector);
Updating the unit tests, RequestInformation and IElasticsearchResponse are gone. What is the paradigm here now?
ie this is a test initialize statement:
searchResponse.RequestInformation = new Mock<IElasticsearchResponse>().Object;
The releases page in github now has all the documentation concerning the breaking changes:
Releases pages
Breaking Changes page for NEST

Adding cabinet file to msi programatically with DTF (wix)

Introduction to the Task at hand: can be skipped if impatient
The company I work for is not a software company, but focus on mechanical and thermodynamic engineering problems.
To help solve their system design challenges, they have developed a software for calculating the system impact of replacing individual components.
The software is quite old, written in FORTRAN and has evolved over a period of 30 years, which means that we cannot quickly re-write it or update it.
As you may imagine the way this software is installed has also evolved, but significantly slower than the rest of the system, meaning that packaging is done by a batch script that gathers files from different places, and puts them in a folder, which is then compiled into an iso, burned to a cd, and shipped with mail.
You young programmers (I am 30), may expect a program to load dll's, but otherwise be fairly self-contained after linking. Even if the code is made up of several classes, from different namespaces etc..
In FORTRAN 70 however.. Not so much. Which means that the software it self consists of an alarming number of calls to prebuilt modules (read: seperate programs)..
We need to be able to distribute via the internet, as any other modern company have been able to for a while. To do this we could just make the *.iso downloadable right?
Well, unfortunately no, the iso contains several files which are user specific.
As you may imagine with thousands of users, that would be thousands of isos, that are nearly identical.
Also we wan't to convert the old FORTRAN based installation software, into a real installation package, and all our other (and more modern) programs are C# programs packaged as MSI's..
But the compile time for a single msi with this old software on our server, is close to 10 seconds, so it is simply not an option for us to build the msi, when requested by the user. (if multiple users requests at the same time, the server won't be able to complete before requests timeout..)
Nor can we prebuild the user specific msi's and cache them, as we would run out of memory on the server.. (total at ~15 giga Byte per released version)
Task Description tl:dr;
Here is what I though I would do: (inspired by comments from Christopher Painter)
Create a base MSI, with dummy files instead of the the user specific files
Create cab file for each user, with the user specific files
At request time inject the userspecific cab file into a temporary copy of the base msi using the "_Stream" table.
Insert a reference into the Media table with a new 'DiskID' and a 'LastSequence' corresponding to the extra files, and the name of the injected cabfile.
Update the Filetable with the name of the user specific file in the new cab file, a new Sequence number (in the range of the new cab files sequence range), and the file size.
Question
My code fails to do the task just described. I can read from the msi just fine, but the cabinet file is never inserted.
Also:
If I open the msi with DIRECT mode, it corrupts the media table, and if I open it in TRANSACTION mode, it fails to change anything at all..
In direct mode the existing line in the Media table is replaced with:
DiskId: 1
LastSequence: -2145157118
Cabinet: "Name of action to invoke, either in the engine or the handler DLL."
What Am I doing wrong ?
Below I have provided the snippets involved with injecting the new cab file.
snippet 1
public string createCabinetFileForMSI(string workdir, List<string> filesToArchive)
{
//create temporary cabinet file at this path:
string GUID = Guid.NewGuid().ToString();
string cabFile = GUID + ".cab";
string cabFilePath = Path.Combine(workdir, cabFile);
//create a instance of Microsoft.Deployment.Compression.Cab.CabInfo
//which provides file-based operations on the cabinet file
CabInfo cab = new CabInfo(cabFilePath);
//create a list with files and add them to a cab file
//now an argument, but previously this was used as test:
//List<string> filesToArchive = new List<string>() { #"C:\file1", #"C:\file2" };
cab.PackFiles(workdir, filesToArchive, filesToArchive);
//we will ned the path for this file, when adding it to an msi..
return cabFile;
}
snippet 2
public int insertCabFileAsNewMediaInMSI(string cabFilePath, string pathToMSIFile, int numberOfFilesInCabinet = -1)
{
//open the MSI package for editing
pkg = new InstallPackage(pathToMSIFile, DatabaseOpenMode.Direct); //have also tried direct, while database was corrupted when writing.
return insertCabFileAsNewMediaInMSI(cabFilePath, numberOfFilesInCabinet);
}
snippet 3
public int insertCabFileAsNewMediaInMSI(string cabFilePath, int numberOfFilesInCabinet = -1)
{
if (pkg == null)
{
throw new Exception("Cannot insert cabinet file into non-existing MSI package. Please Supply a path to the MSI package");
}
int numberOfFilesToAdd = numberOfFilesInCabinet;
if (numberOfFilesInCabinet < 0)
{
CabInfo cab = new CabInfo(cabFilePath);
numberOfFilesToAdd = cab.GetFiles().Count;
}
//create a cab file record as a stream (embeddable into an MSI)
Record cabRec = new Record(1);
cabRec.SetStream(1, cabFilePath);
/*The Media table describes the set of disks that make up the source media for the installation.
we want to add one, after all the others
DiskId - Determines the sort order for the table. This number must be equal to or greater than 1,
for out new cab file, it must be > than the existing ones...
*/
//the baby SQL service in the MSI does not support "ORDER BY `` DESC" but does support order by..
IList<int> mediaIDs = pkg.ExecuteIntegerQuery("SELECT `DiskId` FROM `Media` ORDER BY `DiskId`");
int lastIndex = mediaIDs.Count - 1;
int DiskId = mediaIDs.ElementAt(lastIndex) + 1;
//wix name conventions of embedded cab files is "#cab" + DiskId + ".cab"
string mediaCabinet = "cab" + DiskId.ToString() + ".cab";
//The _Streams table lists embedded OLE data streams.
//This is a temporary table, created only when referenced by a SQL statement.
string query = "INSERT INTO `_Streams` (`Name`, `Data`) VALUES ('" + mediaCabinet + "', ?)";
pkg.Execute(query, cabRec);
Console.WriteLine(query);
/*LastSequence - File sequence number for the last file for this new media.
The numbers in the LastSequence column specify which of the files in the File table
are found on a particular source disk.
Each source disk contains all files with sequence numbers (as shown in the Sequence column of the File table)
less than or equal to the value in the LastSequence column, and greater than the LastSequence value of the previous disk
(or greater than 0, for the first entry in the Media table).
This number must be non-negative; the maximum limit is 32767 files.
/MSDN
*/
IList<int> sequences = pkg.ExecuteIntegerQuery("SELECT `LastSequence` FROM `Media` ORDER BY `LastSequence`");
lastIndex = sequences.Count - 1;
int LastSequence = sequences.ElementAt(lastIndex) + numberOfFilesToAdd;
query = "INSERT INTO `Media` (`DiskId`, `LastSequence`, `Cabinet`) VALUES (" + DiskId.ToString() + "," + LastSequence.ToString() + ",'#" + mediaCabinet + "')";
Console.WriteLine(query);
pkg.Execute(query);
return DiskId;
}
update: stupid me, forgot about "committing" in transaction mode - but now it does the same as in direct mode, so no real changes to the question.
I will answer this my self, since I just learned something about DIRECT mode that I didn't know before, and wan't to keep it here to allow for the eventual re-google..
Apparently we only succesfully updates the MSI, if we closed the database handle before the program eventually chrashed.
for the purpose of answering the question, this destructor should do it.
~className()
{
if (pkg != null)
{
try
{
pkg.Close();
}
catch (Exception ex)
{
//rollback not included as we edit directly?
//do nothing..
//atm. we just don't want to break anything if database was already closed, without dereferencing
}
}
}
after adding the correct close statement, the MSI grew in size
(and a media row was added to the media table :) )
I will post the entire class for solving this task, when its done and tested,
but I'll do it in the related question on SO.
the related question on SO

How to identify and upgrade current installations?

I'm changing our installer to support the possibility of having several versions of our software installed at the same time.
This leads to the scenario where several earlier versions of our product are installed and I need to let the user choose which of the current versions should be upgraded.
Currently I'm using a property called OLDERFOUND to detect if their are older versions at all:
<Upgrade Id='$(var.UpgradeCode)'>
<UpgradeVersion
OnlyDetect='yes'
Property='OLDERFOUND'
Minimum='0.0.0'
Maximum='$(var.Version)'
IncludeMaximum='no'
IncludeMinimum='yes' />
</Upgrade>
On OLDERFOUND a dialog whith a combobox is shown. I dynamically add items to the combobox using a c# CustomAction:
[CustomAction]
public static ActionResult FillVersionList(Session xiSession)
{
View view = xiSession.Database.OpenView("SELECT * FROM ComboBox");
view.Execute();
Record record = xiSession.Database.CreateRecord(4);
//CURRENTVERSIONS is the name of the combobox property
record.SetString(1, "CURRENTVERSIONS");
record.SetInteger(2, 1);
record.SetString(3, "foo");
record.SetString(4, "foo");
view.Modify(ViewModifyMode.InsertTemporary, record);
record = xiSession.Database.CreateRecord(4);
record.SetString(1, "CURRENTIVARVERSIONS");
record.SetInteger(2, 2);
record.SetString(3, "bar");
record.SetString(4, "bar");
view.Modify(ViewModifyMode.InsertTemporary, record);
view.Close();
return ActionResult.Success;
}
What I can't figure out how to do is
populate the combobox with all previous installed versions
and then update the one chosen by the user
I tried to figure out a way to read from the registry to get all versions (I have a registry key for each version installed), but haven't come up with anything. I have no idea how to specify which earlier version to update.
I dont understand why you want the user to select which version to upgrade. When your new product is distributed, it will have an upgrade code/product/package code combination which matches one of the previous installation and it can be used to upgrade ONLY that installation. You wont be able to change that behaviour based on user's decision.
Read more about the upgrade code/product code here:
UPGRADE CODE
Product vs package vs upgrade code

Categories

Resources