I use Android Studio and gradle in my office using a authenticated corporate proxy. This unfortunately means that I have to enter my proxy config including user/pass in cleartext in gradle.properties (or have it automatically propagated from Android Studio's preferences).
However, sometimes I work outside of the office, and I then have to manually go in and comment out my proxy settings each time, which is tedious.
Is there a way to make properties in a gradle file conditional so that the proxy configuration can be automatically activated by detecting if I'm on my corporate network or not? The condition itself could in turn be retrieved either by querying the network adapter for the current network, or perhaps better, by making a simple curl to a known host on my corporate network.
I'm using both Windows and Ubuntu clients but this question mostly applies to Windows.
There might be other ways to solve this I guess, perhaps changing the global gradle settings rather than the project specific ones. To be honest, I have to do a similar git config --add http.proxy, and the same for npm, bower and what not, everytime I change working environments. Other suggestions are welcome even though this question specifically asks how to create a gradle.properties which tries to connect to a known intranet host, and depending on the outcome sets or unsets properties.
I have had the same problem for a while. There was an additional problem for me that gradle.properties are checked in to our VCS with a proxy setting; and I had to take extra steps before all my commits to ignore the changes I did in that file. Additionally, I had to comment/uncomment the same piece of code multiple times in a day.
I could not come up with a conditional update system, but the second problem was resolved by inbuilt shelving functionality in Android Studio and creating changelists to keep 2 copies of the file with different settings.
I don't think there is any way to solve this problem the way you are asking for. For a simple reason: .properties files are not meant to have logic. To quote the Java docs:
Properties are configuration values managed as key/value pairs.
The dynamic settings can be achieved either via Android Studio proxy settings or writing a Gradle task that runs on project load, checks network conditions and sets system properties. I haven't tested this approach, but I think this will also update the gradle.properties file (a side-effect that you may not want). But what is being done by Gradle can also be done via a shell script that you need to execute on project load.
The way I am currently handling proxy update is by entering/saving the proxy settings in Android Studio itself, and toggling when I move between locations. It just takes a couple of commands to bring up the proxy dialog and enable/disable the saved proxy.
Since this proxy file is saved in idea.config.path/options/proxy.settings.xml, you could also try writing a shell script that can toggle the contents based on network availability.
This may not be what you were looking for, but I hope it clears up why it can't be done the way you asked for.
Related
I am deploying a SharePoint 2010 web part that uses the microsoft .net charting tool to build charts. I need the chart handler added to the sharepoint web.configs automatically. I've been told that when you create the wsp the package can be told that when the program is installed it needs to modify the web.config to add these handlers.
I have seen a couple options out there:
-WebConfigModifications
-Safe controls
I don't know which, if any, that I should be using. I don't know for sure if this will be a first time installation for the application (we're moving sharepoint environments at the same time we are updating this. I think that it will be a first time installation on that new environment but can't be sure.)
And I definitely do not know how to implement this correctly. I would appreciate any advice.
Also it may be important to know that I do not have any privileges on the server. I can't even deploy myself.
For example, this seems like good info: http://platinumdogs.me/2009/07/08/using-the-mschart-controls-in-sharepoint-moss-2007/ Except that I can't just write to the webconfig and restart IIS. It has to be automated and not a direct edit to the file.
Thanks all!
I would recommend that you use a Feature Receiver attached to your WSP to create the appropriate SPWebConfigModification entries when your solution's features are activated. Likewise, the SPWebConfigModification entries should be removed when your solution's features are deactivated.
Step 1: Create a Feature Receiver
MSDN has an overview of how to add a Feature Receiver: http://msdn.microsoft.com/en-us/library/ee231604.aspx
Note you'll want to handle both the FeatureActivated and FeatureDeactivating events.
Step 2: Use Feature Receiver events to add or remove SPWebConfigModifications
In those two events, you'll need to programmatically add or remove one or more SPWebConfigModification entries. These affect SharePoint's web.config file, but unlike a manual edit of the config file, they are stored in SharePoint's content database. This means that if the web.config is reset for any reason (and it happens), SharePoint can and will reapply the modifications, thus preserving your changes.
MSDN has an overview of programmatically creating and removing SPWebConfigModifications: http://msdn.microsoft.com/en-us/library/office/bb861909(v=office.14).aspx
It is very important that the FeatureDeactivating event properly clean up all modifications made during FeatureActivated, or you will end up with a proliferation of duplicate config entries. This means you need to really understand how to use the Path and Name properties of the SPWebConfigModification.
This article gives a good overview of how Path and Name are combined to create an XPath expression pointing to the node to be added or removed: http://smindreau.wordpress.com/2013/06/12/finally-the-way-to-add-web-config-modifications-to-sharepoint/
Step 3: Test, test, TEST!
Lastly, test activating and deactivating your solution's feature in your local development environment to make sure everything is working properly. Note that the modifications will be applied via a timer job, so you may need to wait a minute or two to see the changes show up. Be sure the feature deactivation cleans up your modifications! (If you get into a mess in your development environment with duplicate modifications, you can always wipe the slate clean with a little PowerShell action.)
My question is similar to this one, which remained unanswered, unfortunately.
We are rolling out a web application as a web deployment package (Web Deploy/MSdeploy) to different environments. The package is created from within Visual Studio 2012/Team Build. Several parameters are to be set at install time (connection strings, WCF endpoints, logging settings, etc.). We have these in a parameters.xml at the root of the project.
Most of our customers import the package through IIS UI. Each time we roll out an update, customer IIS administrators have to provide the parameter values again through the UI. Most of the time, parameters do not change across updates.
What is the best way to handle this? Advise customer IIS administrators to use the command-line instead, injecting a SetParameters.xml that they keep separately (the level of some of our customer administrators isn't particularly high, so having something UI-based which we can document with a couple of screenshots is an advantage)? Keep the settings file (web.config or appconfig) out of the package altogether? What is the neatest way to do this?
I had the same problem, but decided to go with the batch-script installer file that comes with the web deploy package. In my mind it is more secure, doing this installation by script, instead of having to install through GUI. It can be documented, and maybe they need to learn a little bit of command-line?
As you say, they can use the same SetParameters-file for all following releases, if nothing in it changed - which in my mind is a huge benifit - not having to manage web.configs manually.
Automated deploys minimizes manual errors.
I'm writting a script that sets up a lot of different applications in Windows (mainly svn and open source servers for http, dns, mail, ftp and db). This script is intended to be executed in new/clean Windows workstations for new developers, it automatically sets everything up to create an environment very similar to the one in production. After it's executed, everything runs locally and the developer can start working right away.
This not only helps new developers, but all existing developers whenever there are changes in the whole system, everything is replicated locally.
The one thing I'm still not able to do is making some kind of backup of an IIS server that is running a web app (it's in the Prod server) and restoring it automatically to the new developer's machine so he doesn't have to install/configure IIS locally.
I've read about using appcmd.exe to create and restore backups, but that works only for the same machine (it uses encryption keys and those keys change between computers).
Is there a way, a scriptable way, to take everything IIS related from one server and restore it on another server, without user intervention and having the restored IIS run exactly as the original?
Thanks in advance!
Francisco
Just putting this here so anyone who comes across this will have an understanding as to why this wasn't answered. A website has a massive amount of variables associated with it that prevents any easy methods to copy all of its configuration through one or even just a few cmdlets.
To get started though you would want to become very familiar with the applicationHost.config file and how you access the properties within it using the Get-WebConfigurationProperty. One way to get familiar with how to script against webconfiguration properties is to use the Configuration Editor in IIS. Whenever you make a change in the Configuration Editor, before commiting the changes there is a nifty little link titled Generate Script, which will have a Powershell tab you can use to help you gather the proper Get/Set commands for the configuration elements within the applicationHost.config file.
I've created something almost exactly like what the OP is looking for and it spans 4 modules (over 20,000 lines of code) and has a SQL backend that holds all of the configuration elements.
When a website has everything from underlying DLLs that may need registered, IsapiCGI Restrictions and IsapiFilters, accounts that are tied to the AppPool that may need added to certain local groups on the server, to secure bindings that require a certificate to be loaded on the server. You can see that this isn't a simple undertaking. (and these are just a small portion of the variables that a website may contain)
There is however a large chunk of cmdlets that Microsoft provides you out of the box that you can leverage to aid you in developing something like this inside the WebAdministration module. I know this is four years old but hope anyone who stumbled on this will find the above useful.
I have a web application project in VS2012 which I'm publishing using a "Web Deploy Package". I want this package to include app-pool settings, specifically creating an IIS app-pool and assigning the newly created application to it.
I'm familiar with the option "Include application pool settings used by this Web project" available when the project is configured to use an IIS instance (not IIS Express), but IIS configuration is not part of the project file, and thus not source controlled. What happens when somebody builds a deployment package on a machine that hasn't had IIS meticulously configured? Not ideal.
How else then, can I go about getting AppPool settings into my web deploy package? I understand that the appPoolConfig provider is IIS7+ only, I'm fine with that limitation. I've banged my head against this issue in the past and never found a solution. 18 months later, we've got a new VisualStudio version, and a new web-publishing-pipeline, are there new options to address this? Or maybe something I missed when I first tackled this problem?
Edit
OK, I'm seeing the following as options:
Configure my project to sync settings from an IIS instance. As mentioned, I'm not a fan of this given that it puts settings outside of the project, meaning the environment has to be meticulously configured to build + publish. Plus it drags along other IIS settings I don't want included.
Inject something into the web-publishing-pipeline (WPP) to modify the archive.xml. I've toyed with this in the past and had limited success. One problem is the pipeline isn't exactly co-operative with working directly on the archive.xml file, another problem is some of the more cryptic attributes involved, like MSDeploy.MSDeployProviderOptions which appears to have some Base64 encoded binary? No idea what to put in there.
Find an existing "provider" that can do what I want. I might be out of luck here, the appPoolConfig provider only seems to want to read / write IIS, not, say, an XML file of settings. Does anybody know otherwise?
Write my own "provider" to produce manifest output entries. I'm not sure, is it possible to write a custom provider that writes to a manifest using the name of an existing provider? As in, MyCustomPoolProvider writes appPoolConfig sections into a manifest? This sounds like a potentially painful exercise that may or may not work. Would I still need to figure out the encoding of whatever is going into MSDeploy.MSDeployProviderOptions?
I get the feeling that the fundamental obstacle with Web Deploy for what I'm trying to accomplish, is how strictly it leans on "providers". The pre-existing providers are largely designed for IIS synchronisation, not primary development and publication. It so happens that some of these providers can be relatively easily hooked into via MSBuild, but the majority insist on pulling data from IIS, and that's that.
You are correct in your understanding of the appPoolConfig provider, in that it can only sync between App Pools and can't be provided with the configuration directly. What you could potentially do is keep a copy of the appPool in question in package form (ie. msdeploy -verb:sync -source:appPoolConfig=PoolName -dest:package=apppool.zip) and attempt to hijack the pipeline so that the MSDeploy call adds the application content into the package, leaving the existing content there.
Alternatively, you could always keep the packages separate and deploy them with different calls to MSDeploy.
FYI, MSDeploy.MSDeployProviderOptions is simply an encoded version of the parameters supplied to the provider when it was packaged. For example, -source:dirPath=c:\,ignoreErrors=0x10293847 -dest:package=package.zip would package the ignoreErrors value.
I am aware of weblogic templates, but out of curiosity I wanted to know, Is it ok to copy a domain in weblogic in situations where we need to have the same configuration? I have already done the same and have been successful in testing my application.
You can get away with doing this, but there are a couple of more reliable (and scriptable) ways to migrate the same configuration through the development team, or to create new deployment environments.
The domain template builder lets you build your own custom domain template from an existing domain: http://download.oracle.com/docs/cd/E13179_01/common/docs92/tempbuild/starttb.html
There's a couple of ways to get it done with WLST, as well:
You can use configToScript to spit out an entire WLST script (and properties file) to recreate the exact configuration you've got, or...
You can use readDomain and writeDomain in offline mode to recreate an existing configuration in a new domain:
readDomain: http://download.oracle.com/docs/cd/E13222_01/wls/docs92/config_scripting/reference.html#wp1003638
writeDomain: http://download.oracle.com/docs/cd/E13222_01/wls/docs92/config_scripting/reference.html#wp1003688
It's okay to copy the domains over and it worked exceptionally well prior to WebLogic 9.2. However, there are some weird bugs that pop up for versions that are using the portal for the console.
Also, after copying the file you would want to make sure that all listen addresses and ports have been modified accordingly so that your local managed server doesn't attempt to connect to the production administration server on startup.