MSBuild compiling

Ask general questions here.
bwood
Posts: 16
Joined: Mon Jan 28, 2019 2:52 pm

MSBuild compiling

Post by bwood » Thu Feb 14, 2019 2:55 pm

Hi,

I could not find any information on this anywhere and plan on using MSBuild in my project.
When compiling / executing outside of Ranorex, are all modules executed in order no matter what? I would like to know specifically if unchecked or disabled tests are included in the MSBuild.

Thanks

User avatar
odklizec
Ranorex Guru
Ranorex Guru
Posts: 5052
Joined: Mon Aug 13, 2012 9:54 am
Location: Zilina, Slovakia

Re: MSBuild compiling

Post by odklizec » Thu Feb 14, 2019 3:06 pm

Hi,

MSBuild has nothing to do with started test cases. MSBuild simply builds test to exe file. Enabled/disabled tests are controlled by .rxtst file. By default, test exe starts all enabled modules, as saved during last Ranorex Studio session (saved in rxtst file). If you want to run all/different test cases, you should define and use various Run Configurations (e.g. AllTests, SmokeTest, etc...) and then control the applied run configuration via command line parameters. Hope this helps?
Pavel Kudrys
Ranorex explorer at Descartes Systems

Please add these details to your questions:
  • Ranorex Snapshot. Learn how to create one >here<
  • Ranorex xPath of problematic element(s)
  • Ranorex version
  • OS version
  • HW configuration

bwood
Posts: 16
Joined: Mon Jan 28, 2019 2:52 pm

Re: MSBuild compiling

Post by bwood » Thu Feb 14, 2019 3:14 pm

Yes, that is exactly what I needed! Thanks

User avatar
Stub
Posts: 263
Joined: Fri Jul 15, 2016 1:35 pm

Re: MSBuild compiling

Post by Stub » Thu Feb 14, 2019 3:50 pm

We actually use MSBuild to pull the appropriate version of our Ranorex test code out of source control, build it all, run the resulting .EXE using the command-line parameters Pavel mentioned, and then email interested parties with the (compressed) Ranorex log file (our system is much more complex than that, but that's the gist at least). We make use of parameters (/pa:) and run configurations (/rc:) to control exactly what gets run. This might be a specific test case/smart folder (/tc:) in some cases, but mostly it's the run configuration. Works really well for us.