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.
Related
I am trying to set up references to the CRM 2011 sdk
Microsoft.Xrm.Sdk.dll
Microsoft.Xrm.Portal.dll
Microsoft.Xrm.Client.dll
While trying to use the CrmSvcUtil.exe to generate the early bound types for CRM, I get an error Microsoft.Xrm.Client.CodeGeneration.dll cannot be located. I could not locate the dll in any of the packages that I downloaded using Nuget PM.
Can anybody advise on the usage and how to obtain this?
Use the Early Bound Generator in the XrmToolBox Tool Store. It contains the functionality to generate code using the Xrm.Client. Or if you really just want to use the DLL and do everything by hand, it contains the DLL in the download.
Update
As of March 2020, the EBG no longer supports the deprecated Microsoft.Xrm.Client usage. Hopefully you've transitioned off of that. You can still download older versions of the EBG on NuGet if you're stuck on that client generation.
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?
I have an old project that uses MPXJ library to access MS Project 2010. However it doesn't get the files save as Project 2010 format even if I uses the latest MPXJ 4.0. What else do I need to do to get the files of that format? I've searched MPXJ website but there seems to be no document about the changes and a tutorial to modify existing codes.
you should not need to make any changes to read Project 2010 files. The MPXJ API has not changed significantly with the 4.0 release: there are a few new Task and Resource attributes. If you are using the "presentation" information from the MPP file, you'll find that colors have changed from being represented by an enumeration to being Java Color types. That's pretty much it.
If you are still having specific problems reading Project 2010 files, feel free to raise a bug at SourceForge, or drop me a note directly.
Cheers!
Jon
Disclaimer: I maintain MPXJ
I'm trying to use a custom function in sqlite3.
I found no way in Java to do that so I moved on android-ndk, but now
I'm having troubles integrating sqlite3 sources in my project.
Compiler give me an error 'sqlite3_api' was note declared in this
scope.
In my source "sqlite3ext.h" is included (sqlite3 amalgamation is also included in project).
Any suggestion is welcome!
I had similar problems trying to get SQLite with SEE (SQLite Encryption Extensions) to compile and work. In the end I found http://code.google.com/p/sqlite3-android/ (the 2 downloads dated 17th February, the march downloads added some extra complications that didn't do what I wanted)
Once I had that working I included in the see.c with sqlite3.c and soon got it all working.
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.