I have a multi-project solution which is backed up by NUnit tests for every subproject. The unit tests are passing for other files. Strangely, for the new item added I am getting BuiltInNUnitRunner.cs not found. Tried to restart the system, ensure the .cs file is available. However, VisualStudio 2017 will not pick up from the call stack frame. The screenshot below for more detail call stack
A little late to this party, but in my case I had a typo in a file path of a process that I was trying to open using Process.Start. It was throwing the error described by #Varun Maggo. I was able to figure this out because, in the Unit Testing Output window, the call stack shown in the error message pointed to the line in question.
So it is probable that the error you're seeing is masking the real issue.
Related
I am trying to run msbuild command line, but, I am getting in the last step of it, the error below (it is in portuguese, but is the same error in the title.
C:\Program Files (x86)\Microsoft Visual Studio\2019\Community\MSBuild\Xamarin\iOS\Xamarin.Shared.targets(227,3): erro
r MSB4044: A tarefa "GetMinimumOSVersion" não recebeu um valor para o parâmetro obrigatório "SdkVersion". [E:\2-PROJETO
S\_ALGORIX\Projetos\ACCORD\SOLUTION\AppAlgorix\AppAlgorix.iOS\AppAlgorix.iOS.csproj]
My msbuild command is:
msbuild AppAlgorix.sln /p:Configuration=AppStore;Platform=iPhone /p:CFBundleVersion=1 /p:CFBundleShortVersionString=2.3.1 /p:ServerAddress={mac ip address} /p:ServerUser={mac user} /p:ServerPassword={mac pwd} /p:BuildIpa=true /p:IpaPackageDir="E:\8-IPAS\ACCORD" /t:Clean;Build /p:ArchiveOnBuild=false /p:IsAppDistribution=false /p:CodesignKey="{App ID identifier}" /p:CodesignProvision="{App Provisioning Profile}"
All the {} data are confidential, so I cropped them.
This command was working one day, but I don´t know when, but after some VS 2019 update, the command, stops working.
I have found some articles about it, but I can´t find a way to resolve this problem.
Onw of those articles is this:
https://www.gitmemory.com/issue/xamarin/xamarin-macios/10109/729614745
My VS 2019 is updated in version 16.8.4.
I have here, about 40 apps to build and get the ipa. I was running a dosbat to resolve it, and get those ipas, more quickly. Not having this msbuild command line working, will take me to a big problem, cause I almost every week have some updates in my apps, and build one by one, will not be a great idea.
And one more thing is.. I can build inside VS 2019, without any problem. The problem happens only via msbuild command line.
I used the post Visual Studio update (16.8.1) lead to CI build failures to resolve the error.
"This has reared it's head again in Visual Studio 2019 version 16.8.3.
Looks like they've moved the problem to: \MSBuild\Xamarin\iOS\Xamarin.Messaging.targets I was able to get
my builds running again by removing the _SayGoodbye dependency on line
52 for the _DisconnectAfterClean target."
Although I have resolved the error, now I cant generate the ios.ipa package. Now, I get only the file projectName.iOS.exe, instead of projectName.iOS.ipa.
I dont know if this workaround is the final solution for this bug, yet.
We resolved this by running the build twice in-a-row. (continue on error - ignore the failed first build)
The first time always fails with the error in the question title, but it must somehow sets things up so that the second build has what it needs to succeed. The IPA is generated, etc.
IMPORTANT: DO NOT CLEAN BETWEEN THE TWO BUILDS
I know this solution is a hack workaround, but I prefer it to manually making changes to the .targets files as I have seen suggested elsewhere (those suggestions did not work in our case anyway). Making changes like that without knowing the internals of the build process intimately could result in unintended side-effects.
NOTE: As this solution involves an expected failed partial first build, it does add to the build time, but it was only about a minute or two longer per build, and at least it works reliably.
Hope this is helpful to someone! 🤗
The Pre/Post Build Events in Visual Studio has bugged me for a few years, but I just haven't got around to research a better alternative. The thing that I want to achieve is pretty much the same as I get with Post Build Events: I call a piece of code that does something before or after a project build.
The two things with the Pre/Post Build Events that really bugs me is that (1) the code is separated from my project and compiled into a command line .exe and (2) that every error I get will end up as a cryptical message in the error pane.
I would ideally want to write a static method inside my project that gets called before or after the project builds and if an exception pops up, it gets stack traced like any other exception in debug mode.
What existing (simple) approach can I use to get something like this done?
I am getting my hands on TFS 2010, and I am starting with trying to set a continuous integration build up. For this purpose I am using the default build template (DefaultTemplate.xml) configured with Code Analysis set as Always.
Everything works fine... except when it does not. When there is an error in the build (or a test failure), the only error available in the TFS report is the following
Unable to read Code Analysis output report. Make sure that the directory is writable (default is the project output directory).
The original error is reported only when there is no code analysis. When no error, the code analysis reports are correctly output.
Any ideas?
About the "Unable to read Code Analysis output report" error:
If it happens when compiling in Visual Studio, it could be that the resulting log file path is too long (Ref).
If it happens when compiling in TFS build, it's because the project contains unneeded elements <CodeAnalysisLogFile> and <CodeAnalysisInputAssembly> (Ref).
In our solution, every project imports a Common.Targets file - I intend to override these and thus avoid the problem for all future projects.
What I expect is the following:
Code analysis off, no error: Build is fine
Code analysis off, build error: Workflow does not expect a code analysis file to be generated, original error is displayed, OK.
Code analysis on, no error: Analysis output is generated, and all goes fine.
Code analysis on, build error: Due to build error, code analysis is not performed, the ouput file is not generated. However the workflow expects to find an output file, which it does not find and this becomes the primary error logged in the build exception, hiding the original one.
So please inspect the order of items in your build template, to see if this is applicable and change it to make sure the code analysis output is not expected when a build error occurs.
I have built a solution with msbuild in parallel (/m switch) on our CI server and same error occurs (other file lock specific errors as well, like: The process cannot access the file x.y.z because it is being used by another process). Conclusion: Remove /m because it is not safe :-(
I have been having some problems with the test debugger in VS10. All tests are running without error, but when debugging it aborts when I try to read the object data. Afterwards, this error is displayed in the summary: Test host process exited unexpectedly.
I'm unable to see anymore details about the error. How do I access/generate test-log files? Or, even better: Has anyone experienced a similar problem? And found a solution?
Additional information:
The runtime-test-data is available on objects from same libary assembly, it's just one class I can't get access to in runtime mode. If I use breakpoints at:
every line that affects the object: - I can see the runtime-data and the test passes
only one place: - the test will abort and no data is visible
no breakpoints: - the test runs and passes.
The test used to work fine until recently. Just before the problem occurred when I made some solution changes with dividing the projects into solution folders. I didn't make any changes that should affect the code. Moving the projects back to their original folder don't solve the problem, So I wonder - Is this a bug in Visual Studio itself?
Here is what I've tried so far:
Rebuilding and cleaning the solution.
Closing Visual Studio and rebooting my system.
Installing VS10 Service Pack 1
Reinstalling Visual Studio 10
Testing on VS10 Ultimate and Premium
Removing and regenerating solutions files
Removing all break points
TraceAndTestImpact/Local.testsettings: Testing Timeout > timeout and setting abort to 30 minutes.
TraceAndTestImpact/Local.testsettings: Unit Test > Assembly folders defined
TraceAndTestImpact/Local.testsettings: Deployment > Enable deployment directories and files
How can I fix this? Any suggestions are welcome.
What's most likely happening here is that a property, local which is being evaluated in the locals or autos window is causing a side effect in the running process which leads to the failure. To verify this you should turn off automatic property evaluation
Tools -> Options
Go to the Debugger menu
Uncheck "Enable Property evaluation and other implicit function calls"
Solution:
It had overridden ToString, and as it showed out, there was a loop i forgot to close.
After altering ToSting everything works fine.
Thank you very much for the answers :)
I was getting a similar issue, however in my case ALL tests were being skipped, and the error was reproducible on an empty test project, so code was ruled out.
Checking the EventViewer led me to the cause in my case; somehow the C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\QTAgent32.exe.config file had been removed from my machine?!? I copied one from another machine here and I'm back in action.
I was finally able to resolve this issue in my case. What was happening for me was I was running asynchronous threads, but closed a process using a synchronous Close() method for a powershell runspace rather than the asynchronous CloseAsync() method.
I set a breakpoint in my code in Visual-C++, but when I run, I see the error mentioned in the title.
I know this question has been asked before on Stack Overflow (Breakpoints cannot be set and have been disabled), but none of the answers there fully explained the problem I'm seeing. The closest I can see is something about the linker, but I don't understand that - so if someone could explain in more detail that would be great.
In my case, I have 2 projects in Visual C++ - the production dsw, and the test code dsw. I have loaded and rebuilt both dsws in debug mode. I want a breakpoint in the production code, which is run via the test scripts. My issue is I get the error message when I run the test code, because the break point is in the production code, which isn't loaded up when the test starts.
Near the beginning of the test script there is a mytest_initialize() command. I imagine this goes off and loads up the production dll. Once this line has executed, I can put the breakpoint in my production code and run until I hit it. But it's quite annoying to have to run to this line, set the breakpoint and continue every time I want to run the test.
So I think the problem is Visual C++ doesn't realise the two projects are related. Is this a linker issue? What does the linker do and what settings should I change to make this work?
Thanks in advance. Apologies if instead I should be appending this question to the existing one, this is my first post so not quite sure how this should work.
[Update 1] I think Chris O has identified the problem. I'll add a further update if I'm able to work out how to use the project settings to make this work.
It sounds like you are using VC6, since you mention dsw files. I think that is as good as it gets in VC6, you have to manually add the breakpoint after your module is loaded from LoadLibrary. Actually, there might be a project debug setting, so you can specify which DLLs to load when debugging your project, that will keep your breakpoints enabled when hitting F5.
You can also try attaching the debugger after you know the mytest_initialize() has been called, that might keep your breakpoints enabled.
I had this issue sometimes, but always pass this with some code replacement actions.
Here is some guy post, how he had fixed it.
Hope it helps.
In my case i solved this by setting the DLL project containing the breakpoint as Active Project and changed Debug settings for this project (right-click project>>settings>>Debug tab) to point to the project that actually runs and accesses the DLL. "Executable for debug session:" and "Working directory:" should be set to the executable that you actually want to run and its corresponding directory.
Hope this is of any help.
right-click project>>settings>>Link tab
check on Generate debug info
check on Link incrementally