I'm looking to make a folder outside of a portable electron build.
I'm thinking that creating the folder when the app starts will trigger permissions so I'm hoping to find a way to do it within the build process.
I'm using electron-build for packaging the app.
What's the best way to do that?
Take a look at electron build hook: https://www.electron.build/configuration/configuration#hooks
You might want to put some function such as fs.mkdir at afterPack hook (after pack electron app but before creating installer). Hope this help.
Related
I need to make an MSI from an electron app to bundle with another MSI that is also set to per machine and not per user. It appears this combination of things does not exist.
Electron-Builder squirrelWindows: Allows for MSI creation with squirrelWindows and setting msi boolean to true, but there is no perMachine option.
https://www.electron.build/configuration/squirrel-windows
Electron-Builder NSIS: Has the perMachine option but not for MSIs obviously.
https://www.electron.build/configuration/nsis
Electron-Wix-MSI: Creates MSI, but do not see ability to change the perMachine flag.
https://github.com/felixrieseberg/electron-wix-msi
Windows-installer: Creates MSI, no option for perMachine
https://github.com/electron/windows-installer
EDIT - SOLUTION
These pull request changes on electron-wix-msi fixed my problem:
https://github.com/felixrieseberg/electron-wix-msi/pull/138
I've packaged multiple Electron apps per-machine. It's just a bunch of files. Potentially a whole bunch of files. For the ones with an unpacked node_modules directory I just use heat in a prebuild step to author the components. Other then that it's just like any other app.
I made a pull request/branch on electron-wix-msi tailored to fix my problems: https://github.com/felixrieseberg/electron-wix-msi/pull/138
I'm using TFS 2012 to automate a build of a solution which contains multiple windows services and two web applicaitons.
I've used the guide I found here to customize the build process template so that the windows services are put in a folder structure that I like. Specifically:
\dropserver\droproot\MyApp\BuildNumber\
\Service1
\Service2
\Service3
\Service4
This works great, but unfortunately it doesn't work for web applicaitons. If I used the same strategy for those, I just get the contents of /bin for each web app, rather than the full site contents.
MSBuild typically uses the web application targets to handle this, but for some reason, this doesn't work when you customize the build as I have. I no longer get the _PublishedWebSites folder in the build output. (I'm guessing that's because I cleared our the OutDir property of the MSBuild task.)
Has anybody done something like this and gotten it to work with web applications as well?
I think I can help with this, it looks like in the build targets that the published websites folder isn't created if the OutDir is the same as the OutputPath.
So this isn't perfect, but if you add the following into the csproj file in the first property group, you'll get everything deployed into "\bin\deploy\" including the _PublishedWebsites folder
<DeployOnBuild>True</DeployOnBuild>
<OutDir>bin\deploy\</OutDir>
With a bit of customization, this solution ended up working for me:
http://www.edsquared.com/2011/01/31/Customizable+Output+Directories+For+TFS+2010+Build.aspx
Basically, did what that link recommended, but also leveraged a new solution configuration (which I called TeamBuild) rather than conditional property definitions.
I believe the key to making this all work was the passing of the outputDirectory as the TeamBuildOutDir argument to MSBuild. Embedding this variable reference in the OutDir or OutputPath variable was allowed Team Build to build to the correct staging location and then automatically copy files from that location to the drop folder.
I'm going to take this a little futher and get rid of the whole _PublishedWebSites thing, but that will be done entirely in the build workflow.
EDIT: TFS 2013 supports this natively with a simply build configuration option:
Take a look at this thread as this post as well.
Team Build: Publish locally using MSDeploy
Since you need all the files for your web projects, you need to trigger the publishing process, and by tweaking the destination of that process, you can have all of your files copied where you need them.
I think option (2) from his answer will work for you.
I hope that helps.
As I can see in your reference link, it will just compile and package the binaries. It does not deploy the website by the steps mentioned in that.
If you want to get the .html, .css, .js etc. under the _PublishedWebSites folder, you need to do a Web Deployment. This manually we can do by clicking the publish option from right click menu of your VS project and by selecting Publish Method as File System.
But, since you need to automate this in your build and drop it in custom drop folder, you may need to manipulate your MSBuild script by calling a AspNetCompiler task. You can get more information on this at the MSDN link. By specifying the TargetPath while you call this target you can get your Web files deployed at the appropriate custom drop folder.
Happy Scripting.
Have you check this blog, this solved my problem where I wanted customized TeamBuild Ouput Directory.
Customizable O/P with TFS 2013
Customizaable O/P with TFS 2012 and .NET Framework 4.5
Just starting out with the Trigger.io workflow. Was wondering if anybody could enlighten me as to the deal with different projects in different directories. I've inadvertently created another test application through my local Trigger Toolkit via the terminal, and have noted (after some searching) that it has created a new app project deep within my ~/Library/Trigger Toolkit/ directory. The original app I created (via the web interface) was plonked in /Users/[Name]/[Name of App].
When I forge run/build it runs the local version deep within the Trigger \Toolkit directory, not the version within my Users directory. How can I register this one with my local build? And destroy the test created with the local build.
If you know what the hell I'm trying to get at then you deserve a stack overflow crown.
Not sure how you've managed to get an app appearing in ~/Library/Trigger Toolkit. This overview might help:
The folder structure for a forge app is something like:
my-app/
local_config.json
src/
config.json
identity.json
index.html
The forge commandline program tries to treat the current working directory as an app (i.e. it expects you to run it in a folder like my-app above).
The exception is forge create which sets up this structure. For example if you ran forge create in /Users/tim/my-app then it would set up something like the above.
The Trigger Toolkit has two actions for dealing with these sorts of folders - create and import. The create action sets up an app structure like the above, the import action allows to import the my-app folder above into the list of apps available to work on in the Toolkit.
You can remove an app from the list by using the "forget" button next to the app in the list. If you want to "destroy" an app it always comes down to just deleting a folder, in this case I'd delete the my-app folder.
The folder ~/Library/Trigger Toolkit contains the code for the Trigger Toolkit itself, as well as a file which keeps track of the apps listed in the Toolkit. The only way I can see that you'd get an app appearing in this folder is to manually cd to it and use forge create.
To summarise, each app is isolated to a folder. When using the commandline tools you just need to use e.g. forge build android and forge run android in the specific folder for that app. If using the Toolkit you need to import the folder or have created it through the Toolkit, clicking that app in the app list puts you in the context of it, and run/package actions from there will run using the folder registered for that app.
I have the following scenario: The company edits aspx/xml/xslt files and copy manually to the servers in order to publish them. So, no build is done. For the sake of control we've decided to adopt TFS Preview since it tracks the version, who edited and so on. Needless to say, it works like a charm. :)
The problem is that since we are unable to build the apps we can't set a build definition to automate the copy of files to another place which, as I've stated before, is done manually.
My question is: Is it possible to copy the files to another place (a folder in a server or local) during the check in? If so, how? (remember, we don't build. so we can't customize the build process...)
You have two options.
1) Create a custom check in policy. I'm not familiar with this process enough to give you any pointers, but I believe it can be done.
2) Create a custom build template, and use that for your builds. You should be able to wipe the build template down to nothing, and then only add the copy operation to it. This is probably the route I would take. Get started here.
You mention you are using TFSPreview, which is hosted on the cloud so it won't be able to access any machines in your network unless you're prepared to open up your firewalls :).
You can copy source controlled files around the TFS Instance ([say into a Source Controlled Drop F1) and then check this out after the build completes.
Start by familiarising yourself with customising the TFS Build Process.
When you're up to speed, you need to look at adding a "Copy" Activity in the Workflow to move the files to the drop folder.
I work on a site where none of us have used TFS before, but we are now having to do so.
As a result there are some odd issues that I need to sort out.
Where I have an application say APP, when I build my application a new APP.dll is created.
I have found that when I build and deploy my application, I have to check in this into source control on TFS 2010.
That is fine when I am working on this my myself. But how should I manage this when I am working in a team? Everyone will want to compile their own version of APP and will need a different APP.dll as a result.
I am sure there is a simple solution to this. I look forward to finding out what it is.
Do not store your build assemblies (*.dll) in source control, but use the build that is available for you in TFS. The Build system will compile all the sources and drop the created binaries in a folder share. You can use the files in the share to distribute / deploy your application.
You can find more information on the build at http://msdn.microsoft.com/en-us/library/ms181709.aspx