I'm building an Electron App using electron-builder on macOS.
In my code I access the command line args like this:
const cmd = electron.remote.app.commandLine;
const val = cmd.hasSwitch('myArg')
? cmd.getSwitchValue('myArg')
: undefined;
This works fine for the production build on macOS when providing the arguments:
./my-electron-app.app/Contents/MacOS/my-electron-app --myArg=foo
// or:
open my-electron-app.app --args -myArg=foo
But on Windows I can't get it working.
Here's what I tried using cmd.exe:
my-electron-app.exe --myArg=foo
my-electron-app.exe -myArg=foo
my-electron-app.exe /myArg=foo
my-electron-app.exe myArg=foo
When logging electron.remote.process.argv[1] I can see the passed arguments on macOS and Windows, but hasSwitch and getSwitchValue won't give me the value.
What am I doing wrong? Or is there a better way to get cross platform command line arguments working?
I'm gonna take a guess that this is because of the capital letters in your switch. See this closed issue:
This is intentional. The hasSwitch API is a direct wrapper of the Chromium CommandLine class, which behaves this way on purpose.
From Chromium source:
Switch names must be lowercase.
Though it's not totally clear to me yet why Mac doesn't suffer from the same problem.
We are trying to access some of the experimental features of Docker with DOCKER_BUILDKIT. We see that this works fine on Mac and Linux, just not Windows. Any idea how to get this to work on Windows?
The ability to build Windows images is a known limitation of buildkit. You can subscribe to and add your vote to this issues on the roadmap if you are interested in the feature:
https://github.com/microsoft/Windows-Containers/issues/34
Otherwise, for building Linux images, buildkit should work the same on Docker for Windows as it does on other environments, with either the DOCKER_BUILDKIT=1 environment variable for the feature flag set in the daemon.json file (configurable from the Docker preferences UI):
{ "features": { "buildkit": true } }
Note that the environment variable overrides the feature flag on the engine. You can also use buildx which is another method to access buildkit. This has the same limitations as accessing buildkit directly (mainly you cannot build Windows images).
It works for me using Docker Desktop for Windows
Try to add the following to your daemon.json:
"features": { "buildkit": true }
I use docker within powershell and this worked for me:
# for docker build ...
$env:DOCKER_BUILDKIT = 1
# for docker-compose build ... (additional!)
$env:COMPOSE_DOCKER_CLI_BUILD = 1
This worked for me without any changes in the settings (as described in some other answers).
I know it is pretty late for answer but....
better late then never.
First of all, in docker desktop, go to settings >> docker engine and make sure you have everything set as shown below
{
"registry-mirrors": [],
"insecure-registries": [],
"debug": true,
"experimental": false,
"features": {
"buildkit": true
}
}
"features": {
"buildkit": true } is set to true by default i believe.
But mark that debug is set to true, while by default it is set to false.
So you will probably have to change it.
And second of all. The most obvious thing that is realy hard to find in documentation.
Unlike on ubuntu, you DO NOT actualy add DOCKER_BUILDKIT=1 at the start of your build instruction.
Personaly, it was extremaly confusing for me, because im so used to adding this phrase from Linux systems. But in Windows, if you enable the options as shown above, buildkit option will always trigger by default.
This is a general question though I haven't found where I am going wrong.
Using Windows Server with Azures kudu stand alone to host a local project.
Also using React, Webpack, Redux
Windows environment var is set to production
Package.json has set NODE_ENV=production && etc.. for
both start and build scripts
web.config has iisnode node_env=production
running node I get the node_env is indeed production
However when I build it's giving me the development build when I do something like
if (process.env.NODE_ENV === 'production') {
module.exports = require('./buildProduction.js')
}
else {
module.exports = require('./buildDevelopment.js')
}
What gives?
I came to the same conclusion and searched why this is and thanks to neagtivetwelve for the comment # https://github.com/webpack/webpack/issues/1720
In short setting
new webpack.DefinePlugin({
'process.env.NODE_ENV': JSON.stringify('production'),
}),
fixes the issue. Instead of
new webpack.DefinePlugin({
'process.env.NODE_ENV': process.env.NODE_ENV,
}),
Even though I have in the build script to set the session NODE_ENV var and set within the system environment vars I would still get the wrong result until this change was made even though opening node from cmd and typing process.env.NODE_ENV yields the correct result.
Anyway I hope it helps someone else.
We are having the same issue found here, here, here and here
Basically we upgraded to xcode 6.1 and our build are getting the "ResourceRules.plist: cannot read resources" error.
We have a Jenkins server that does our ios builds for us. We are using the Xcode plugin on Jenkins to do the actual build and signing. Any thoughts on how we can make this change without manually opening xcode and doing this solution found on the other answers:
Click on your project > Targets > Select your target > Build Settings >
Code Signing Resource Rules Path
and add :
$(SDKROOT)/ResourceRules.plist
I'm very new to Xcode and iOS build in general. I have found the project.pbxproj file inside the Unity-iPhone.xcodeproj file. It looks like this contains the build settings under the /* Begin XCBuildConfiguration section */ section it lists what looks like similar build properties foundin Xcode, however I do not see anything like "Code Signing Resource Rules Path".
Does anyone have experience manually editing this file? Is that a bad idea in general?
Thanks
If you're using Jenkins with the XCode plugin, you can modify the 'Code Signing Resource Rules Path' variable by adding:
"CODE_SIGN_RESOURCE_RULES_PATH=$(SDKROOT)/ResourceRules.plist"
to the
'Custom xcodebuild arguments' setting for the XCode plugin.
This fix does not require the XCode GUI.
I encountered the same problem. Nicks solution does work, but is requiring additional dependencies. You don't need the heavy-handed npm xcode module for this. Just add a line to this file:
$PROJECT_ROOT/platforms/ios/cordova/build.xcconfig
CODE_SIGN_RESOURCE_RULES_PATH=$(SDKROOT)/ResourceRules.plist
Note that before XCode 6.1.1, this needed to be specified as "$(SDKROOT)/ResourceRules.plist" (notice the quotes).
If you are running this inside automated build systems such as Jenkins and wont't/can't use any XCode GUI, just create a small Cordova hook, leveraging npm's fs.appendFile, at this location:
$PROJECT_ROOT/hooks/before_build/ios_resourcerules.js (make sure it has chmod +x)
#! /usr/local/bin/node
var fs = require("fs");
fs.appendFileSync('build.xcconfig', '\nCODE_SIGN_RESOURCE_RULES_PATH = $(SDKROOT)/ResourceRules.plist', function (err) {
if (err) throw err;
console.log('CODE_SIGN_RESOURCE_RULES_PATH added to Cordova iOS build configuration.');
});
This will might be merged in an upcoming Cordova release, so the hook will become unnecessary (i'm creating a see this PR for Cordova-iOS).
In case the above JavaScript snippet fails to execute due to a "wrong argument" failure, replace the file's content as follows:
#!/bin/bash
if [ ! -f ./build.xcconfig ]; then
echo "[ERROR] hook befor_build/ios_resourcerules.sh cannot execute, ./build/xcconfig not found in $PWD"
exit 1
fi
echo '// (CB-7872) Solution for XCode 6.1 signing errors related to resource envelope format deprecation' >> ./build.xcconfig
echo 'CODE_SIGN_RESOURCE_RULES_PATH=$(SDKROOT)/ResourceRules.plist' >> ./build.xcconfig
echo 'CODE_SIGN_RESOURCE_RULES_PATH added to Cordova iOS build configuration.'
If you want to get really crazy, you can directly update PackageApplication.
# In /Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin/PackageApplication
my #codesign_args = ("/usr/bin/codesign", "--force", "--preserve-metadata=identifier,entitlements,resource-rules",
"--sign", $opt{sign},
"--resource-rules=/Applications/Xcode.app/Contents/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS.sdk/ResourceRules.plist");
# OLD: "--resource-rules=$destApp/ResourceRules.plist");
I was already hacking this script to accept a keychain arg, so it made sense for me. Note I'm not using the Xcode Jenkins plugin -- I'm using Jenkins but running all the build commands from a script.
After the new release of XCode 7 on 23rd Sept 2015, Apple started rejecting any application that is using CODE_SIGN_RESOURCE_RULES_PATH, making the Jenkins build automatically rejected. However, setting CODE_SIGN_RESOURCE_RULES_PATH=$(SDKROOT)/ResourceRules.plist into the Custom xcodebuild arguments causes a build failure.
This answer resolved the issue: https://stackoverflow.com/a/32762413/5373468
This is clearly a bug that Apple forgot to fix a while ago, as this article is also highlighting: http://cutting.io/posts/packaging-ios-apps-from-the-command-line/
I had EXACTLY the same problem, as you have. We are building our iOS app on Jenkins, so we couldn't manually set "Code Signing Resource Rules Path".
I have wrote a small NodeJS file which does the job for me (see the code below).
The script use a nice NodeJS package called xcode which helps me with the parsing of the xcode.xcodeproj file.
I don't know if you are using Cordova/Phonegap or what you are using, but if you are can just copy the code and make a Cordova hook. If not I'm sure you can execute the file from Jenkins, with some small changes.
Anyways, I hope this script will help you:
#!/usr/bin/env node
var CODE_SIGN_RESOURCE_RULES_PATH = '"$(SDKROOT)/ResourceRules.plist"';
var fs = require("fs");
var path = require("path");
var xcode = require('xcode');
var projectRoot = process.argv[2];
function getProjectName(protoPath) {
var cordovaConfigPath = path.join(protoPath, 'www', 'config.xml');
var content = fs.readFileSync(cordovaConfigPath, 'utf-8');
return /<name>([\s\S]*)<\/name>/mi.exec(content)[1].trim();
}
function run(projectRoot) {
var projectName = getProjectName(projectRoot);
var xcodeProjectName = projectName + '.xcodeproj';
var xcodeProjectPath = path.join(projectRoot, 'platforms', 'ios', xcodeProjectName, 'project.pbxproj');
var xcodeProject;
if (!fs.existsSync(xcodeProjectPath)) {
return;
}
xcodeProject = xcode.project(xcodeProjectPath);
console.log('Setting Code Sign Resource Rules Path for ' + projectName + ' to: [' + CODE_SIGN_RESOURCE_RULES_PATH + '] ...');
xcodeProject.parse(function(error){
if(error){
console.log('An error occured during parsing of [' + xcodeProjectPath + ']: ' + JSON.stringify(error));
}else{
var configurations = nonComments(xcodeProject.pbxXCBuildConfigurationSection());
for (config in configurations) {
var buildSettings = configurations[config].buildSettings;
buildSettings['CODE_SIGN_RESOURCE_RULES_PATH'] = CODE_SIGN_RESOURCE_RULES_PATH;
}
fs.writeFileSync(xcodeProjectPath, xcodeProject.writeSync(), 'utf-8');
console.log('[' + xcodeProjectPath + '] now has Code Signing Resource Rules Path set to:[' + CODE_SIGN_RESOURCE_RULES_PATH + '] ...');
}
});
}
var COMMENT_KEY = /_comment$/;
function nonComments(obj) {
var keys = Object.keys(obj),
newObj = {}, i = 0;
for (i; i < keys.length; i++) {
if (!COMMENT_KEY.test(keys[i])) {
newObj[keys[i]] = obj[keys[i]];
}
}
return newObj;
}
run(projectRoot);
We are using Unity + Jenkins for auto builds.
You can achieve with post process cs scripts; however; for quick (and dirty fix) you can apply following bash command after Unity but before xcode:
sed -i '' 's/CONFIGURATION_BUILD_DIR/CODE_SIGN_RESOURCE_RULES_PATH = "\$(SDKROOT)\/ResourceRules\.plist";\'$'\n CONFIGURATION_BUILD_DIR/g' /Users/admin/Jenkins/workspace/PROJECTNAME/Build/PROJECTNAME/Unity-iPhone.xcodeproj/project.pbxproj
I'm trying to override the absoluteUrl in combination with a deployment on a Windows server.
On the server in Meteor.startup I'm doing this:
Meteor.absoluteUrl({rootUrl: "http://example.com"});
Calling Meteor.absoluteUrl() in the console returns: http://localhost:3000.
Any suggestions are most welcome. Doing this Meteor.absoluteUrl({replaceLocalhost:true}); also doesn't have any effect at all.
Try:
Meteor.absoluteUrl.defaultOptions.rootUrl = "http://mydomain.com"
In your Meteor.startup. If its not for individualizing settings you can also use the environmental variable ROOT_URL