Welcome to Typemock Answers. Here you can ask and receive answers from other community members. And if you liked or disliked an answer or thread: react with an up- or downvote Enjoy!

Default LogPath is invalid when AutoDeploying TypeMock 8.2 in TFS 2013 Build

0 votes
I am using TFS 2013 and I have upgraded my AutoDeploy files from 7.5 to 8.2 recently. I noticed there are a few new arguments that I can provide to TypeMockStart activity. I came across an issue that my tests are somehow still addressing 7.5.6 of TypeMock although I can not find why nor where that is configured. While I was investigating this issue I noticed the LogPath somehow is not configured correctly by default, please review the screens below for more information. I have tried to override the value but although the field is supposed to be of type String I keep getting the message that the L-values expression is invalid. So instead of trying to implement a workaround I think my best option is to get the original problem solved: it should work by default. 
<tt:TypeMockStart 
  LogLevel="{x:Null}" 
  LogPath="{x:Null}" 
  Target="{x:Null}" 
  Version="{x:Null}" 
  sap2010:WorkflowViewState.IdRef="TypeMockStart_2" 
  ProfilerLaunchedFirst="False" 
  Verbosity="[BuildVerbosity.Diagnostic]" />

The snippet above results in a LogPath where a \ is obviously missing, considering the verbose build-output (focus on the filename) below:

Execute TypeMockStart, Version=8.2.3.20

TypeMockStart Target=, ProfilerLaunchedFirst=False, Link=, LogLevel=3, LogPath=C:\Users\OntwSvUsTfsBuild\AppData\Local\Temp\TypemockTFSBuild_20160112085119.log, EvaluationFolder=,DisableAutoLinkFalse

TypeMockStart Normal=Autolink 6442450944

TypeMockStart Normal=Log Directory C:\Users\OntwSvUsTfsBuild\AppData\Local\Temp\TypemockTFSBuild_20160112085119.log does not exists, Changing to default directory: E:\Builds\15\BZR.Net\BZR_Main_AT\src\Client.Build.Binaries\

TypeMockStart Normal=Typemock Isolator Logging to: E:\Builds\15\BZR.Net\AZR_Main_BT\src\Client.Build.Binaries\

There is a folder Typemock in my Temp-folder, but that is not what the activity is trying to write to. It now concatenated a path that is a filename TypemockTFSBuild_20160112085119.log which does not exist. The strange thing here is that it is changing the default directory to a COMPLETELY IRRELEVANT directory that has NOTHING to do with the currently running build. It is a completely different project and it could potentially contain other AutoDeploy-files! Why would you default-to a previously used folder instead of some static Temp-location? 

Then I tried to workaround this issue by overriding the LogPath argument, simply by setting the string-value. I have not managed to finish that as Visual Studio keeps warning me that the value is invalid. Maybe I have worked too hard and try again tomorrow, but what is wrong with setting the LogPath with the value below?

<tt:TypeMockStart 
  EvaluationFolder="{x:Null}" 
  Link="{x:Null}" 
  LogLevel="{x:Null}" 
  Target="{x:Null}" 
  Version="{x:Null}" 
  DisableAutoLink="False" 
  sap2010:WorkflowViewState.IdRef="TypeMockStart_2" 
  LogPath="[Environment.GetFolderPath(Environment.SpecialFolder.LocalApplicationData) + &quot;\Temp\TypeMock\&quot;]" 
  ProfilerLaunchedFirst="False" Verbosity="[BuildVerbosity.Diagnostic]" />

The LogPath value above is copied from the XAML source. Visual Studio in Design-Mode shows a message about an "Invalud L-value expression" that I can not explain considering the type of String that is used. 

Your insights about all of the questions above is highly appreciated. 

 

asked Jan 12, 2016 by rpaardekam (680 points)

3 Answers

0 votes

Hi Robin,

Can you confirm that you've overriden typemock.dll and typemock.arrangeActAssert.dll with the same files in version 8.2  and checked them in to TFS

If you have access to the server you can simply open a test project and check the path of typemock and typemock.arrangeActAssert references and then check which version of these files you have on the server machine in the same path.

 

The logs that you've mentioned are diagnostic, all the information about test run is available in the regular output.

 

Alex Galin | Support Team

answered Jan 12, 2016 by alex (17,910 points)
Hi Alex. I'm 100% sure: the assemblies in the project as well as the assemblies checked into TFS (referenced by the build controller so copied to each of the build-agents) both are 8.2.3.20. When viewing the files locally on the buildagent after the build I have inspected the assemblies and they are all of the same version.

Could you validate if you can reproduce the issue of the invalid LogPath? Also, I amwondering why there is a unrelated fallback-path when that path seems to be invalid: that potentially could result in strange results, don't you agree? I wouldn't mind adding new Questions for each of the mentioned issues if you prefer. Thanks.
Hi Alex, any news yet about these topics? Questions that still remain are:

- Can you verify the LogPath is invalid because of a missing \-sign in the path?

- How can I overrule the value with a string that I compose myself?

- Why is a fallback-path used that is not related at all to the currently running build?

Thanks
0 votes
I think I must user "answer" instead of "comment" to get attention to my pending issues? :)
 
- Can you verify the LogPath is invalid because of a missing \-sign in the path?
- How can I overrule the value with a string that I compose myself?
- Why is a fallback-path used that is not related at all to the currently running build?
 
 Thanks
answered Jan 14, 2016 by rpaardekam (680 points)

This issue is taken offline.

So far: 

-Invalud L-value expression fixed

-Default log path is set to local  appdata

-the log path is being created if it doesn't already exist

- "\" wasn't missing in the path, I'd elaborate but it's embarrassing so I won't blush

 

Alex Galin | Support Team

0 votes
Solved in version 8.3

Thanks for reporting it

 

Alex Galin | Support Team

answered Feb 11, 2016 by alex (17,910 points)
...