We're using Tridion 2009 SP1 with XSLT templates
A brand new multimedia component (v0.0) and its uploaded binary file
will be correctly published to the preview site at the point it is
first saved (publishing of the binary is done by the
tbbPublishMultimedia template, shown below).
The multimedia component will enter workflow as minor revision
version v0.1 and whilst in workflow (at "Prepare Edition Content
Item") the component can be edited and the binary file re-uploaded
into the component by the author as required.
Each time the v0.x component is saved in workflow (as v0.1, v0.2,
v0.3, v0.4 etc) the latest "in workflow" version of the component
and its binary file will be correctly published to the preview site.
Each time the multimedia component is approved for publishing it
leaves workflow and becomes a new major version (e.g. v1.0.... or
v2.0, v3.0 etc).
If a major version is subsequently edited and re-saved it becomes a
new minor revision version (e.g.v1.1) it will then be re-published to
the preview site (as will its binary file) and it will then re-enter
workflow.
However, while Tridion correctly publishes the latest minor revision
version of the actual multimedia component (e.g. v1.1) it seems to
publish only the last major version of the binary file it contains
(e.g. the v1.0 version). Interestingly, it does appear to publish the
latest v1.1 metadata for that binary file (i.e. file type and
file size) but not the binary file itself.
In summary, Tridion appears to publish the latest minor/revision "in
workflow" version of the binary file if the multimedia component is v0.x
but once a major version exists it will only publish the last major version
of the binary file (essentially the version prior to it re-entering
workflow).
That's what it looks like anyway...
<xsl:template name="tbbPublishMultimedia">
<xsl:if test="string(//tcm:Type)='Multimedia'">
<xsl:variable name="binaryid"
select="string(//tcm:Component/#ID)"/>
<xsl:element name="tcm:MultimediaPublishedFileName">
<xsl:value-of select="tcmse:PublishBinary($binaryid)"/>
</xsl:element>
</xsl:if>
</xsl:template>
Note... in the above template its possible to specify a major version as
the tcmse:PublishBinary parameter e.g concat($binaryid,"-v2") to
determine which version to publish, but as it doesn't let you specify a
minor version so that doesn't really help much
I really haven't done much with XSLT templates lately, not sure I can help. Anyway you can confirm is this is only with XSLT or does it happen also with other templates? If it only happens with XSLT then you may be facing a bug, while if it happens to all other languages then it could simply be "by design" and there's not much you can do about it other than opening an Enhancement request.
I found recently that if I ask for version 0 (tcm:1-23-16-v0) of any item Tridion will return the latest version of the item that the current user is allowed to read, including minor versions (in c#). Maybe you can give that a try?
Related
The problem
I have a Qt IFW installer with an online repository, from which users fetch data to install and update the software.
My installer has a "root script" defined in config.xml:
<Installer>
<!-- ... -->
<ControlScript>controllerscript.qs</ControlScript>
</Installer>
Now I want to change the content of controllerscript.qs and deploy it on the online repository.
when a new user installs the software for the first time, it works as expected
when a user updates its software from a previous version using MaintenanceTool.exe, it does not get the update
Possible solution
I realized that when you create the installer, it generates a file named MaintenanceTool.dat which seems to contain controllerscript.qs (+ other things). I managed to manually copy that file and push it to the online repository (inside a package). That way, the maintenance tool is able to see the package update, and correctly gets the new MaintenanceTool.dat. After that, the maintenance tool is indeed using the new code from controllerscript.qs.
Question
Is there another (cleaner) way to achieve that?
If not, is it really safe to provide a manual update to MaintenanceTool.dat? That file contains many other things, so is there a risk to interfere with the rest?
Thanks,
I know there's https://dotnet.microsoft.com/download for most Linux versions, but I wasn't able to get any of them running on my Raspberry. I was lucky to find a blog with the direct link for wget.
I'm not asking for current links, I'm asking for how i can get the current stable version for future releases, or even better where i find links for every version available.
Look at the real download page: https://dotnet.microsoft.com/download/dotnet-core/3.0
You can find links to ".NET Core binaries" under the "Linux" section for each release on that page.
These are not stable links - each time there is a release, you will have to look and and find the link to the latest release (a new row in the table) manually.
You should use the "ARM64" or "ARM32" links depending on what your Raspberry Pi version is.
These binaries are "portable", meaning they should work irrespective of what distro you are using (as long as it's a recent-enough distro).
I'm trying to import an XML generated in MS Project 2016 into another system, but the XSD I have seems to be from an older version. I've only been able to find it for 2007 and 2010. I can probably tweak what I have to account for the differences, but it would be nice to not have to. Are schema definitions for newer versions of Project available somewhere?
Sadly I'm not sure they exist. I look for updated versions periodically but I haven't come across any yet.
The most recent version I have has the filename mspdi_pj15.xsd, and the comment in the file says Revision date: 2012-07-18. This was extracted from the Project 2013 SDK.
One word of warning is that regardless of MS Project version changes, the XSDs don't match what Project actually reads and writes in a few areas. I use the XSD to generate JAXB code as part of MPXJ, and I've had to make a number of manual revisions to the published XSD to get it work correctly. Unfortunately I'm not sure that publishing the changes is possible as the original file is copyright Microsoft and doesn't mention redistribution.
I am trying to evaluate the ITHit WebDav Server Engine Library as I would like to implement a feature to have the ability to modify different versions within Word.
I am using Word Office 2013 and I am wondering if its possible to show the versions in the word document, under Info tab and then under Versions (next to manage versions button).
I have followed the steps through the wizard to generate the code. I have selected
1) 'store files and metadata in SQL DB'
2) Delta V support checked
3) 'auto-put under version control before the first update' and 'allow auto versioning' as checked.
I have tried editing the word file, saving and opening it again. However, I am not able to see the list of versions under the Versions tab. Maybe the versions can only be seen through the AJAX File browser plugin, if thats the case, is there a way to show the different versions available for the document file which was send to the client ? Do I need to extend an interface of IFile or IVersion etc?
Unfortunately Microsoft Office is using its proprietary protocol extensions to manage document versions, it is not using WebDAV. As a workaround you can manage versions via Ajax File Browser.
Currently DavEngine class contains AllowOffice12Versioning property which enables versioning in MS Office UI. However this property is experimental and currently marked as internal. It is available for source codes license owners only.
In all of my other .net apps my build process (a mixture of nant and custom tasks) automatically updates the [AssemblyVersionAttribute] AssemblyInfo.cs with the current build number before the call to msbuild, stamping in the build number in the version number.
I'm now working on my first BizTalk project and I'd like to do the same thing with the version numbers of the BizTalk assemblies, but I've run into trouble!
First of all the aseembly version numbers are stored in the btproj files, so I did some googling and found www.codeplex.com/biztalk which looked like the answer to my problem, but there is a deeper problem!
I have a project for my schemas and another for my pipelines, the pipelines project references my schemas project as I have a flat file dis/assemblers. The problem comes when I update the version numbers, as updating them even from within visual studio does not update the pipeline components references to the schemas.
So if I update all the version numbers manually in the VS IDE from 1.0.0.0 to 1.1.0.0, the build fails as the pipeline components flat file dis/assemblers still reference the old 1.0.0.0 version of the schemas! They don't automatically update!
Is this really a manual process of updating the version numbers of the BizTalk projects in the property pages, then building the projects and manually updating the references to them in the properties of all the pipeline components that reference them?
This means that I can't have my build process control the build number part of my version numbers!
Or is there a better method of managing the version numbers of the BizTalk assemblies?
I'm sorry to disappoint you but I've been down the exact some road I had to give up. I guess it could be possible to achieve it but it would require a lot of changes to both the binding files and other XML files (as you mentioned and even more if you have published services etc).
Maybe it could be possible to wrap all these necessary changes in a build step (a MSBuild step or similar in other build frameworks) - that would be useful!
Developer- :)
We had the similar problem and we ended up developing a small utility which would change the version number in all the projects i.e. *.csproj (asssemblyinfo.cs), *.btproj accordingly. Apart from this it would open and modify the *.btp files with the new version of schemas. In nutshell, what all you have to do is to configure this utility in your VS.net tools menu and execute it.
I guess its not very difficult to develop such utility in any .net lanagauge.
Caveat: Do not forget to save the files after updates with the same encoding as they were originally.
Cheers!
Gutted, thought that might be the case. Maybe BizTalk 2009 projects will play more nicely when updating references when changing version numbers.
I started to go through and automate it manually, and when I realised what needed to be done, I took a biiig step back when I realised just how many places I'd have to modify to get it working. Thank god for Undo Checkout.
I do have a standard C# class library included in my project (various helper functions), which i am able to update the version number of during my build process, so I'm basically using that one assembly to version the whole application. If anyone wants to know what version is in any environment, check out the version number of that one assembly.
Not ideal, but it's working.
We've done this successfully on our project - I'll see if I can get the developer of the tool to post details...
This problem arises when you perform an integration build to the latest versions of your dependent components as file references (aka schemas here).
Keep in mind that upgrading the assemblyversion must always performed manually, that way you are always in charge of changes to assemblyversions.
A possible solution to solve the buildbreaks issue is to file reference to a specific version of a dependent component build and not to the latest version and use a subst drive and a copy script to get the latest component builds.
For example:
SchemaA, assembly version 1.0.0.0
PipelineA (with pipelinecomponent XMLValidator for example), assembly version 1.0.0.0
PipelineA has a file reference to a subst drive(say R drive, which maps to a workspace D:\MyComponents) and version 1.0.0.0 of SchemaA as follows:
R:\SchemaA\1.0.0.0\SchemaA.dll.
The copy-script copies the buildoutput of SchemaA locally to your R drive.
When schema A updates to version 1.1.0.0 you don't have any issues because you still use version 1.0.0.0 and YOU have the choice to use the 1.1.0.0 version of your schema. When you want to upgrade, you have to alter your copy-script and replace the file reference to R:\SchemaA\1.1.0.0\SchemaA.dll.