我使用MsTest框架实现了数据驱动测试.
我想知道是否有办法从TestContext对象获取当前测试代码的迭代/行号？
据我所知,与DDT相关的唯一属性是DataRow,它允许从数据源获取当前迭代的信息,但我没有看到任何属性给我我需要的东西.
我有一个小的可执行文件,我作为Azure Web角色的启动任务的一部分运行.我使用RoleEnvironment.GetConfigurationSettingValue从可执行文件中的cscfg读取一些设置,这很好.我得到了反馈,建议使用CloudConfigurationManager.GetSetting,但是当我尝试它时,该方法返回null(设置未找到).我可以在门户网站上看到我想要阅读的设置.
我看到有些人在CloudConfigurationManager上遇到了类似的问题,并询问了它:1.这里:CloudConfigurationManager.GetSetting返回null 2.这里:CloudConfigurationManager.GetSetting在生产中返回空字符串？
但解决方案始终是关于更新Azure SDK和所有引用,这对我不起作用.
(我们使用Azure SDK v2.0,并且所有引用都指向相同的版本.我也验证了这是在VM上运行时加载的版本)
提前感谢任何线索!
我有一个脚本a.cmd调用另一个脚本b.cmd,并重定向其输出.被调用的脚本,启动永不终止的可执行文件.可执行文件的输出重定向到其自己的日志文件.简化代码:
a.cmd:
[1] @ECHO OFF
[2] SET LOG_FILE_NAME="log.txt"
[3] REM Start the b.cmd redirecting all output
[4] CALL b.cmd >> %LOG_FILE_NAME% 2>&1
[5] ECHO returned to a.cmd >> %LOG_FILE_NAME% 2>&1
[6] EXIT /B 0
b.cmd:
[1] @ECHO OFF
[2] SET ANOTHER_LOG_FILE_NAME="log2.txt"
[4] ECHO RunForEver.exe redirecting all output
[5] START CMD /C "RunForEver.exe >> %ANOTHER_LOG_FILE_NAME% 2>&1"
[6] ECHO b.cmd execution complete
[7] EXIT /B 0
(为方便起见,添加了行号)
我遇到的问题是b.cmd中的第4行似乎抓住了初始日志文件(LOG_FILE_NAME)上的句柄,因为所有b.cmd输出都被重定向到它,并且在可执行文件(和启动它的cmd正在运行.我没有这个行为,因为我认为只有start命令本身的输出将被重定向到LOG_FILE_NAME日志文件,而实际运行RunForEver.exe可执行文件的另一个进程的输出将被写入ANOTHER_LOG_FILE_NAME.因此,a.cmd中的第5行错误输出,拒绝访问LOG_FILE_NAME.
有人可以解释发生了什么吗？有办法避免这种情况吗？
我尝试从b.cmd中对LOG_FILE_NAME执行输出重定向,但后来我在b.cmd的第2行中得到了拒绝访问错误.
提前致谢!