Is there a way to just point ".vscode/launch.json" to a profile defined in my "Properties/launchSettings.json" so I don't need to duplicate those values?
I need to support several different editors and also run from command line with
dotnet run --launch-profile="myprofile"
This is in the docs: https://github.com/OmniSharp/omnisharp-vscode/blob/7095cdad1549686d6786df18e36c2db0cf76b24c/debugger-launchjson.md
"launchSettingsProfile": "${workspaceFolder}/<Relative-Path-To-Project-Directory/Properties/launchSettings.json"
Related
Issue running into I have one selenium code that need to be run in different environments. One by one .the code in environment(sit) type a keyword and generate list of terms , another environment (prod) do the same thing but generate different list. I need to validate the first appearing term from the list in sit and prod .the code is failing because what is in sit is different from prod .Is there generic way that can be used to run one code on both environments even if they generate different results .Can you please direct me ?
There are several ways to achieve that.
One of the most appropriate (imho) ways to address environment independance is to use environment variables.
Another is to use property files holding different properties for different environments
Another one is to use your execution environment specific properties (like jvm properties in Java).
Options 1 and 3 are imho the most suitable for integrating your code into CI process.
You can passed those values via config file and read and use it in your test code
I have two team builds created in VS 2013 - Dev and Test - using the TfvcTemplate.12.xaml build process template. Both builds also use a custom .proj file defined in the process tab "Build/Projects" parameter.
Dev is set to Continuous Integration to build on each check-in. For the Test build, I'd like to update to a particular version.
When firing the build manually, in the parameters tab, I have successfully been able to specify a Changeset in the "Get Version" option. (C9999)
1) I'd like to eventually fire this build from command line, so is it possible to pass this in as a /msBuildArgument instead? e.g. /p:GetVersion=C9999
(I've tried this, and it successfully passes GetVersion to my .proj files, but it does not override the iBuildDetail.SourceGetVersion, which I think is what needs to happen to tell MSBuild what version to get from source control.)
2) Would using the "Label", "BuildId" or "BuildNumber" be better options, and if so, can I specifiy them as /msBuildArguments?
I have found a few related posts, but these offer suggestions that don't seem directed to 2013, but rather 2010 and 2008.
This screenshot shows where I can successfully enter and build a specified changeset and what I'm attempting to pass via arguments.
I found some buried documentation which indicates to prefix the label with an "L". Setting Get Version = "LlabelName" did the trick.
https://msdn.microsoft.com/en-us/library/gg490833.aspx#VersionSpecs
This is helpful, but it seems the labels are tied the to the build's retention policy. For this reason, I'll be using Changesets to specify the version I want to get (build and deploy).
Also, I found a couple parameters to specify Changeset (or labels) to add to the TFSBuild start command I am executing from the command line:
/getOption:Custom /customGetVersion:C9999 (or LlabelName)
Somewhat related to this question - Parametrizing node name in Elixir Exrm - is there a way to dynamically set the content of the rel/vm.args file?
In the title, I suggest the use of config.exs, but I'm interested in any scheme that will allow me to add, remove and edit vm arguments at build time.
A bash script might be an idea, but a solution that would also work on Windows, and is preferably based on Elixir code would be the idea.
You can commit to your project repo a rel/vm.args file that you would like to be used instead of the Exrm generated one. Exrm will automatically use this file instead.
How can I specify which import file I want hibernate to run. Is there any configuration option that I can put (I think I have seen something like this somewhere) that I can say custom .sql file and hibernate will run it.
I want to split my creation into multiple files. And also I want to run differnet scripts that will generate date based on my hibernate config that I am using. So if I am using local it should one set of .sql files and if I am testing it into QA it should use another.
I have multiple config files that I can run depending on what I want, so now I need to figure out how to put which script should run in which configuration.
cheers
'hibernate.hbm2ddl.import_files' is the setting you want (org.hibernate.cfg.AvailableSettings#HBM2DDL_IMPORT_FILES).
http://docs.jboss.org/hibernate/orm/4.1/javadocs/org/hibernate/cfg/AvailableSettings.html#HBM2DDL_IMPORT_FILES
So I'm looking here and I see the command line switches. http://mono-project.com/Command_Line_MoMA
This is what I see as the total amount of switches from the site:
MoMA.exe --nogui --out C:\app\momareport\report.html C:\app\myapp.exe
One thing I see is the submit.xml going to a place I don't want during my automated build. Since it is a generated file, I want to change where it goes. Is there a switch for that?
Also, what are all of the switches for it?
If there is not a switch for moving the submit.xml to a reporting location, please consider it for future versions.
EDIT: The argument --help does not work. I tried that and a host of others to try to get some dialog from MoMA on the command line. I'm on Windows to help alleviate any confusion.
Those are the only command line switches supported by MoMA. You can see the code here.
"MoMA.exe --help" does not work because MoMA is compiled as a winforms application so that the command window is not shown. As a result, MoMA disconnects from the command window, and therefore things like Console.WriteLine will not work.
To answer your actual question, there is currently not a way to change where the .xml file gets put.
You might want to try:
MoMA.exe --help
On Linux, there should also be a manpage.
If you can't find the feature, and want to submit it to Mono, you'll want to go via the Bugzilla page.