Is there a method when creating dita-ot 2.1 pipeline to only output the
topic.fo and not go on to create the PDF?
Regards
Conteh
As far as I know there is no such a parameter available by default.
If you look in the ANT build file "DITA-OT/plugins/org.dita.pdf2/build.xml" there is a "transform.fo2pdf" target. I guess you could manually make changes to the build file in order to avoid calling this target from the "transform.topic2pdf" target.
Change:
<target name="transform.topic2pdf" depends="copyCoreArtwork,transform.topic2fo,transform.fo2pdf"/>
To:
<target name="transform.topic2pdf" depends="copyCoreArtwork,transform.topic2fo"/>
Related
I am using version 21 of the Oxygen XML Editor and the DITA Map WebHelp Classic (deprecated) Transformation Scenario. I have a folder that contains HTML files I want to open in a new window/tab, so that are xref'd in my XML file such as:
[<b><xref href="External/aFile.html" format="html" scope="external">Some Text</xref></b>]
I have a PostProcess batch script that I manually run that does an xcopy of the External folder to Oxygen's out/webhelp folder, and I would like to instead run it automatically in Oxygen after the Transformation is done. Is there I way I can do this?
Two ways:
1) Use your custom ANT build file in the Oxygen transformation scenario:
To use a custom build file in a DITA-OT transformation, follow these steps:
Use the Configure Transformation Scenario(s) action to open the Configure Transformation Scenario(s) dialog box.
Select the transformation scenario and click Edit.
Go to the Advanced tab and change the Custom build file path to point to the custom build file.
As an example, if you want to call a custom script before running the DITA OT, your custom build file would have the following content:
<project basedir="." default="dist">
<!--The DITA OT default build file-->
<import file="path/to/DITA-OT3.x/build.xml"/>
<target name="dist">
<!--Call the DITA OT default target-->
<antcall target="init"/>
<!-- You could run your script here -->
<!--<copy></copy>-->
</target>
</project>
2) Create your own DITA Open Toolkit plugin which adds a new transformation type with a custom ANT build file which calls the WebHelp transformation type and afterwards can perform the copy operation:
https://www.oxygenxml.com/doc/versions/21.1/ug-editor/topics/whr-xslt-customization.html
I created this project https://github.com/RemiBou/RemiBou.CosmosDB.Migration, for working it needs the user to do 2 things : create the appropriate folders and edit the csproj so the file inside those folders are embedded.
Before we could do that automaticly when installing with install.ps1 but this feature has been deprecated. Do you know any way how I could do this ?
install.ps1 isn't exactly deprecated, but it's a feature unique to packages.config. PackageReference has no concept of install as anyone can simply edit the csproj and add a PackageReference. When you restore, NuGet has no way of knowing if this is the first time the package is restored for the project after the reference was added, or if it's just the first time the project was restored with a clean repo (after a "msbuild /t:clean" or "git clone", for example).
I don't know an alternative for creating the folders other than having documentation that says the convention is to use that folder name. But, an alternative to modifying the csproj is to take advantage of the fact that MSBuild is a generic build system and NuGet packages can include MSBuild props and targets file.
In your specific case, I would create a props file that defines a property something like <RemiBouCosmosDBMigrationPath>CosmosDB\Migrations\</RemiBouCosmosDBMigrationPath>, which allows your package users to change the property to a different path be overwriting the property value in their csproj, if they prefer.
Then create a targets file which contains a target something like
<Target name="RemiBouCosmosDBMigrationsEmbedMigrations" BeforeTargets="???">
<ItemGroup>
<EmbeddedResource Include="$(RemiBouCosmosDBMigrationPath)**\*.js" />
</ItemGroup>
</Target>
You'll need to figure out what the best target name to put in the BeforeTargets attribute, but I hope you understand the idea. A csproj file is nothing more than a MSBuild file with certain conventions. MSBuild files can import other MSBuild files, and MSBuild and NuGet work together to allow MSBuild to import MSBuild files that come from restored packages. Just compose the MSBuild properties and items in a different way, and the end result can still be the same.
I'm using TeamCity to build and publish my .NET core application to NuGet.
I've been using the project.json file for storing the version, but with the latest version of .NET core the project.json file has become obsolete, since everything has moved to the project's .csproj file. So I'm trying to find a new home for the version information.
Here are some possibilities that I can think of.
Continue using project.json, but only for storing the version information (doesn't feel like a permanent solution)
Storing the version in a separate file like version.txt
Somehow storing it in GitHub using tags or something alike. This feels like the ideal solution.
I like option 3. the most, e.g. for storing release points (1.0, 2.0, etc.) and then using some date time appended afterwards. But I'm unsure if that's possible or even recommended.
What is the recommended way of storing the version information, given that you have your project in GitHub and that you're using the latest .NET core?
Is there a problem with having it in the .csproj file?
As for recommendations - there are various ways you do this which you choose is up to you.
With .NET Core the assembly information can be specified in the project file (.csproj). How you have it defined in the project file is up to you.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
<OutputType>Exe</OutputType>
<TargetFramework>netcoreapp1.0</TargetFramework>
<AssemblyVersion>1.4</AssemblyVersion>
</PropertyGroup>
</Project>
You could have it hard coded. Or run some other MSBuild task to generate it.
AssemblyFileVersion and AssemblyInformationalVersion should work in the same way.
When you build the project an AssemblyInfo.cs file is generated in the obj/Debug/netcoreapp1.0/ directory.
We are using TFS2010 for our web sites's builds and we're in the process of creating fully automated builds. At the moment the sites are built and deployed in remote servers.
The sites contains several configuration files that we would like to transform as part of the build. As there are some rules to create the correct config files we would like to use a custom tool for that purpose (.exe), not to use xml transformations for it.
From what we can see in the build template, MSBuild copies the files to a drop folder and then pushes them to the remote IIS site. We would like to hook our custom tool to this process and do the transformations in the build server before the site is published. The problem is that the MSBuild task is a single node in the build template and we can't find a place where to invoke our tool. Before the MSBuild step, there is no code deployed to the drop folder, after the MSBuild step the code was already deployed to the remote server.
Any ideas on how to plug the custom tool in the correct workflow step?
What is the msbuild target, that you use? I think you can define your own target in csproj file to do the following:
execute your custom tool against required files
run usual build target (or whatever target you normally use)
Edit
E.g. in a .csproj file you could define the following:
<Target Name="buildWithCustomTool">
<!-- Exec your custom tool -->
<Exec Command="your command" />
<!-- Call the build target which will run as normally -->
<CallTarget Targets="Build" />
</Target>
Hope it helps,
Ivan
My VSIX extension has project templates with custom project file. This file contains a reference to my .targets file which is installed as a part of VSIX extension (so it's in my extension's folder). My problem is that I can't find any variable that indicates the VS extensions path, which is needed to find a target for the projects file.
If there is still something like:
<Import Project="$(VSExtensionsPath)\MyCompany\MyExtension\MyLang.targets" />
that would be great.
If not, is there any other way? Maybe I can run a script during vsix installation?
<Import Project="$([System.IO.Directory]::GetFiles($([System.IO.Path]::Combine($([System.Environment]::GetFolderPath(SpecialFolder.LocalApplicationData)), `Microsoft\VisualStudio\11.0\Extensions`)), `Your.targets`, System.IO.SearchOption.AllDirectories))" />
No, custom MSBuild targets aren't supported in VSIX in VS 2010. There is no way to do a "custom action" during VSIX install time.
One possible solution (may not be good for your situation though) would be including the targets directly in the project file template.
If this isn't feasible, then unfortunately you won't be able to use VSIX to deploy your extension.