I need this because the license information, I'm looking a way to know if the app is running in debug or production mode.
If the app is running in debug mode, I need to use Windows.ApplicationModel.Store.CurrentAppSimulator
otherwise I need to use Windows.ApplicationModel.Store.CurrentApp
So, I'm looking for a implementation of the function isDebug:
var currentAPP;
if (isDebug()) {
currentApp = Windows.ApplicationModel.Store.CurrentAppSimulator;
} else {
currentApp = Windows.ApplicationModel.Store.CurrentApp;
}
Any tricks?
Debug.debuggerEnabled
tells you if a debugger is attached.
Note that this isn't the same as "It was compiled as debug" -- since JS isn't compiled that isn't really a meaningful indicator.
Take a look at WinJS are there #DEBUG or #RELEASE directives?
The answer there references a handy NuGet package (https://www.nuget.org/packages/WinRT-JsDebugSymbols/1.0.0) which once added and referenced in your app enables a simple check to see if it was compiled with the Debug profile:
if (Debug.isDebugBuild) {
//spot to put debug build only code
}
Given that both these methods are not entirely reliable, there is another approach through which you pick up the build target setting directly from Visual Studio, and then use that to bring in a debug or release file.
Here's how. Create two .js files in the project (debug.js and release.js in a js-buildinfo folder) and make sure to exclude them from the end package by setting their Package Action to None instead of Content (right click, select Properties, and you'll see the actions under Solution Explorer).
Here are basic file contents:
debug.js:
(function () {
"use strict";
WinJS.Namespace.define("BuildInfo", {
isDebugBuild: true,
isReleaseBuild: false,
config: "Debug",
currentApp: Windows.ApplicationModel.Store.CurrentAppSimulator
/*
* Include debug-only data, service URIs, access tokens, accounts, etc.
*/
});
})();
release.js:
(function () {
"use strict";
WinJS.Namespace.define("BuildInfo", {
isDebugBuild: false,
isReleaseBuild: true,
config: "Release",
currentApp: Windows.ApplicationModel.Store.CurrentApp
/*
* Include release-only data, service URIs, access tokens, accounts, etc.
*/
});
})();
You'd then use BuildInfo.* anywhere in your code you need to differentiate. Better still, encapsulate build-specific stuff in these files as much as you can, e.g. the CurrentApp vs. CurrentAppSimulator, calls to WinJS.Log.startLog, etc.
Then use an MSBuild task to selectively copy one or the other file to a common name in the package (e.g. buildinfo.js). To do this, it’s necessary to add a BeforeBuild action in the project file. At present, VS doesn’t allow custom build configuration for JS projects through the UI, so you have to do the following:
Editing the .jsproj file I added the following entries under the ItemGroup with the project files:
<ItemGroup>
<BuildFlagSource Include="js-buildinfo \$(Configuration).js" />
</ItemGroup>
<ItemGroup>
<BuildFlagDestination Include="js\buildinfo.js" />
</ItemGroup>
And then farther down there’s a section that’s commented--you uncomment it and add the element shown here:
<Target Name="BeforeBuild">
<Copy SourceFiles="@(BuildFlagSource)" DestinationFiles="@(BuildFlagDestination)" OverwriteReadOnlyFiles="true" SkipUnchangedFiles="true" />
</Target>
<Target Name="AfterBuild">
</Target>
<PropertyGroup>
<DisableFastUpToDateCheck>true</DisableFastUpToDateCheck>
</PropertyGroup>
Ideally you’d make buildinfo.js read-only in the project to prevent editing what will be overwritten in the build.
And the you can just have this line in whatever HTML files need it (usually before other .js files that would use the BuildInfo properties):
<script src="/js/buildinfo.js"></script>
Things I like about this solution:
A few downsides:
But it does work and is the closest I've come to precompilation directive with other languages.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With