Is there a way to read value for the WiX variable from a text file?
What I am trying to do is to include a version-specific information into instlal package.
This version information extracted into the text file on the pre-build step,
the question is how to propages this text file content into a build process.
One of the possible solution is to update whole .wxs file on the pre-build step
too, but it feel a bit sloppy.
Is there any other, less-intrusive way?
Thank you.
Create a separate file 'includes.wxi', for example like this:
<?xml version="1.0" encoding="utf-8"?>
<Include Id="VersionNumberInclude">
<?define MajorVersion="1" ?>
<?define MinorVersion="5" ?>
<?define MicroVersion="99" ?>
<?define BuildVersion="14954" ?>
</Include>
In your wxs file, you can include this file like this:
<?include VersionNumberInclude.wxi ?>
And the defines can be used like this:
<?define VersionNumberInternal="$(var.MajorVersion).$(var.MinorVersion).$(var.BuildVersion)" ?>
<?define VersionNumberUserVisible="$(var.MajorVersion).$(var.MinorVersion).$(var.MicroVersion).$(var.BuildVersion)" ?>
In my environment, WiX scripts are always built by the MSBuild file. That means that I can pass in any version-specific information I want on the command line. CruiseControl.NET passes these version numbers to my WiX script when built.
Related
I'm tyring to refactor my code using include-what-you-use, but I need to figure out exactly which directories VS is looking in.
How do I get a listing of all include paths visible to files in my project?
If I add an incorrect include, something like "#include " I get the listing I want, but I can't copy and paste the damn thing! (and OCR doesn't seem to work).
How do I get this list?
Copy/pasting from the dialog is ok if you want to do this once manually but doesn't scale well. Since you tagged this msbuild, here's a solution using it. Create a file names showincludes.targets and paste this msbuild code:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<Target Name="ShowIncludes">
<Message Text="$(Include);%(ClCompile.AdditionalIncludeDirectories)"/>
</Target>
</Project>
Now to get the list of includes for any project file use
msbuild \path\to\vcxproj /p:ForceImportAfterCppTargets=\path\to\showincludes.targets /t:ShowIncludes
This will import said file into the project give, so it has access to all properties, and print out the value of the INCLUDE environment variable which is by default used by the compiler, and also the value of AdditionalIncludeDirectories which is passed to the compiler by msbuild.
In the Qt Installer Framework, all of the demos have TargetDir specification that (for Windows) place the application in, e.g., C:\InstallationDirectory. How can I have it default to Program Files?
<?xml version="1.0" encoding="UTF-8"?>
<Installer>
<Name>Your application</Name>
<Version>1.2.3</Version>
<Title>Your application Installer</Title>
<Publisher>Your vendor</Publisher>
<StartMenuDir>Super App</StartMenuDir>
<TargetDir>#RootDir#InstallationDirectory</TargetDir>
</Installer>
There is no option for this, but you can create use the Component Scripting interface to set the installation directory, as described here.
First, in your packages/com.myorg.myapp/meta/package.xml file, include this reference to the script file.
<?xml version="1.0" encoding="UTF-8"?>
<Package>
...
<Script>installscript.qs</Script>
</Package>
The installscript.qs file, which should be in the same directory as package.xml, should be the following:
function Component()
{
var programFiles = installer.environmentVariable("ProgramFiles");
if (programFiles != "")
installer.setValue("TargetDir", programFiles + "/MyPath");
}
Now the installer framework will suggest C:\Program Files\MyPath or C:\Program Files (x86)\MyPath, as needed.
Finally, if you want to allow installation paths with spaces (like C:\Program Files\MyPath), you need to enable that specifically in config/config.xml by adding this line:
<?xml version="1.0" encoding="UTF-8"?>
<Installer>
...
<AllowSpaceInPath>true</AllowSpaceInPath>
</Installer>
From Qt Installer Framework >= 3.0
You can now use the ApplicationsDir variable, and it'll default to C:\Program Files on Windows, /opt on Linux and /Applications on OS X.
<?xml version="1.0" encoding="UTF-8"?>
<Installer>
...
<TargetDir>#ApplicationsDir#/InstallationDirectory</TargetDir>
</Installer>
Reference: http://doc.qt.io/qtinstallerframework/scripting.html#applications-directory-on-windows
I am writing VQMod XML to edit config.php in opencart, i wrote below XML and saved it inside XML folder.
<modification>
<id>VQMOD CORE FOR OPENCART - DO NOT REMOVE</id>
<version>1.4.x and 1.5.x</version>
<vqmver>2.2.1</vqmver>
<author>Senthil</author>
<file name="./config.php">
<operation>
<search position="after"><![CDATA[
define('DB_PREFIX', 'op');
]]></search>
<add><![CDATA[
define('HTTP_IMAGE_2', 'http://localhost/opcart/image/');
define('HTTPS_IMAGE_2', 'http://localhost/opcart/image/');
define('DIR_IMAGE_2', '/Users/[username]/Sites/opcart/image/');
]]></add>
</operation>
</file>
But its not creating new cache file in vqcache folder as its doing for other files. No errors in log file. I have write permission to the vqcache folder and config file. Any help will be useful.
vQmod's do not work on those files. It works basically on all php/tpl files above the index.php folder (ie 1 or more files deeper)
Yes this is possible. You can use VQMod everywhere that a file is accessed, as long as there is a logical chain of "touch" to that file and no rogue requires. In this case, this is semi-untested beyond a dev instance, and there are "security" risks involved with making configs moddable.
To do it, you just need to edit index.php (and admin/index.php). Move the following to the top of of the index.php's (under define VERSION) so that it comes before the check for config.php's:
// VirtualQMOD
require_once('./vqmod/vqmod.php');
VQMod::bootup();
Then change the way OC is pulling config.php:
require_once('config.php');
By adding in the check for mods:
require_once(VQMod::modCheck('config.php'));
Access your catalog/admin so VQ can build, then check /vqmod/vqcache for file:
vq2-config.php
If it's there, and your changes are in, success.
PS: You can just use <file name="config.php"> in your XML file, no need for the relative ./.
Looking for some help from anyone that's worked with SlowCheetah to transform config files under a web project. We're finding that partial config files referenced from the web.config are not being transformed.
For example, we've included references to partial configs AppSettings.config and ConnectionsString.config in the web.config like so:
</system.web>
<connectionStrings configSource ="ConnectionsString.config"></connectionStrings>
<appSettings configSource ="AppSettings.config"></appSettings>
</configuration>
and then in the AppSettings.config we have just the AppSettings section like so:
<appSettings>
<add key="LostPasswordBCC" value="knock#timmons.com" />
</appSettings>
and finally in the transform file AppSettings.Debug.config we have some additions:
<?xml version="1.0" encoding="utf-8" ?>
<!-- For more information on using transformations
see the web.config examples at http://go.microsoft.com/fwlink/?LinkId=214134. -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<appSettings >
<add key="Release" value="Something" xdt:Transform="Insert" />
</appSettings>
</configuration>
Obviously the above is just a test to see the transform occur, but what we're finding is that on attempting to preview the transform all we get back is an error "There was an error processing the transformation." The publish attempt also fails.
If we make the config files fully formed xml and not referenced from web.config, the transformation seems to work fine - but were looking to share these files across multiple projects.
Does anyone know if there's a workaround where we can both reference partial configs from the web.config and also have transforms off those partial files? We're dealing with legacy code with a large number of config files across multiple web projects that were attempting to consolidate, thus the need to link from web config to separate shared files.
Problem has been resolved, turns out after help from Sayed, we determined that in our efforts to understand the config transformation process with a web project we had corrupted the transform config file's format. With freshly created config files we were able to get transforms to work using SlowCheetah.
This allowed us to move on the real problem we needed to address which was wanting to transform project configs other than the web.config using Visual Studio 2012's publish profiles. This did not work originally, but again Sayed helped us out and provided a new copy of SlowCheetah that allowed this to work.
Below is a link to the new version of SlowCheetah with the fix: https://github.com/sayedihashimi/slow-cheetah/issues/46
Much thanks for all your time and patience Sayed.
I am trying log some entries in a log file (Log.Trace / Log.Debug) while my VS unit test runs. I have also copied the file NLog.config to out directory through DeploymentItem attribute over class. Still my log file is not created. Any help as to how can we log entries in a file same as we do for normal web application.
I've just found a solution to this problem:
Add the App.config file to yout unit test project with the following contents:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<configSections>
<section name="nlog" type="NLog.Config.ConfigSectionHandler, NLog"/>
</configSections>
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<targets>
<target name="debugLog" xsi:type="Console" />
</targets>
<rules>
<logger name="*" minlevel="Debug" writeTo="debugLog"></logger>
</rules>
</nlog>
</configuration>
You may put any configuration you wish as with NLog.config file.
Unfortunately that is the only XML solution at the time. It is not only about Unit Testing, though. NLog.config does not work with just any Console Application.
Do not know if it is by design or just an oversight. Anyway I would not say that moving NLog.config to App.config section is any way satisfactory =/
Maybe it is worth to notice that there is a possibility of configuring nlog directly from code, what could be helpful in some scenarios.
One could be also glad to find nlog debug option, that will log the whole process of processing configuration file, registering targets and so on...
To turn it on, just add internalLogFile and internalLogLevel attributes to nlog element:
<nlog xmlns="http://www.nlog-project.org/schemas/NLog.xsd" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" internalLogFile="C:/logs/nlog.txt" internalLogLevel="Debug">
or from code:
InternalLogger.LogFile = #"c:\logs\nlog.txt";
InternalLogger.LogLevel = LogLevel.Trace;