prevent vstest discovery engine locking DLLs - visual-studio-2012

I have some C# unit tests for a VS2012 project which calls a VS2010 c++ DLL using DllImport pinvoke.
As a pre-build event for the test project, I copy the latest version of the DLL to the binary project for the test.
This repeatedly fails if vstest.discoveryengine is running. It appears that the 'discovery engine' is loading the tests and holding the lock on the DLL.
If I kill vstest discovery engine, then I can build and run the tests. otherwise the build fails, and VS2012 offers to run a previous version ( with a model dialog which doesn't have a 'don't show this message again' option)
Is there something I can do to either force the test project to unload the DLL when not actually running the tests, or to disable the background discovery executable?
I've hacked a workaround by creating an executable called Kealakekua which kills vstest.discoveryengine.x86, vstest.executionengine.x86, and with that as the first part of the pre-build event it can copy the files and build, but would prefer not to be fighting visual studio for my file.

I recently also had this issue and the problem was caused by my own user code.
During test discovery all the test classes are instantiated and in one of our test class constructors, a quite complex business classes was initialized. The problem is that during initialization of it a background thread was created, that did the following:
socket.Read(...)
This thread kept running forever waiting for some socket data to arrive and as a result locked our assembly.
So the solution for me was to make sure this code won't get called during test discovery.
You can check, if you are affected by this issue, by attaching Visual Studio to the test discovery engine when it has locked some assembly. After pressing pause you normally will see, that the current executing line is somewhere in your own user code (also check the Threads window).

I had a similar problem where I created a "Test" project that didn't actually have any tests in it. (As a C++ Library developer I wanted to make sure that certain headers were able to be compiled with CLR enabled, so I made a fake CLR project to just compile them with CLR. If it compiled, it passed.) The DLL created was being held open indefinitely by the vstest.discoveryengine.
I fixed it by adding an Ignored test to the project. I think vstest.discoveryengine will hold on to the dll until it finds all the tests in the dll, but if there are no tests to be found, then it will hold onto it forever.
The test I added (I think it is the default test) Note the TEST_IGNORE() to make sure it isn't executed:
#include <CppUnitTest.h>
namespace CLRTests
{
TEST_CLASS(CLRTestsClass)
{
public:
BEGIN_TEST_METHOD_ATTRIBUTE(CLRTest1)
TEST_OWNER(L"")
TEST_DESCRIPTION(L"")
TEST_PRIORITY(1)
TEST_IGNORE()
END_TEST_METHOD_ATTRIBUTE()
TEST_METHOD(CLRTest1)
{
// TODO: Your test code here
}
};
}
I hope this is possible in your situation.

Related

How to Determine Which Dll Dependency is Failing to Load in Windows Store/Universal Apps?

When running a UWP project I'm working on I receive the following dialog.
"Unable to activate Windows Store app 'MyAppsMangledName'. The 'MyExeName' process started, but the activation request failed with error 'The App didn't start'."
The Visual Studio output has the following.
The thread 0x3d4c has exited with code -1073741515 (0xc0000135).
The thread 0x3b50 has exited with code -1073741515 (0xc0000135).
The program 'MyExeName' has exited with code -1073741515 (0xc0000135) 'A dependent dll was not found'.
The Event Viewer has 3 events that basically restate the popup dialog in 3 different ways and nothing else.
Running Process Monitor during the startup shows me many dlls being successfully loaded but nothing indicating failure besides some NAMENOTFOUND events which unfortunately don't show what name wasn't found.
In Win32 a helpful dialog usually indicates which dll could not be loaded. And of course with .Net apps the fusion logs make tracing this very straight forward. But for Store/UWP apps I can't seem to find a good way to track down the offending dependency.
This just hit me too on a project I'm working on. And after much digging, someone on my team was able to figure it out. So figured I'd share it for others struggling with the same issue.
We're doing UWP with C++ using VS2015. So with that in mind, there is a program called gflags located for me at C:\program Files (x86)\Windows Kits 10\Debuggers\x64\gflags.exe
So you'll want a cmd window with admin, and run the command gflags.exe -i your-program-name.exe +sls
Note: gflags wasn't in my path so either add the path or navigate to where it is before executing the command.
Just pass in the name of the exe without directories. What it does is sets a registry setting for VS that turns on sls (show loader snaps) for exe's matching that name. Then run your application in VS and and you'll get a large amount of dll loading information including names of the dlls that fail to load in your output window. In our case it was this:
5038:34f4 # 789320468 - LdrpProcessWork - ERROR: Unable to load DLL: "vccorlib140d_app.DLL", Parent Module: "E:\projects---\Source\Builds\vs2015_Debug_UWP_x64\AppX---.exe", Status: 0xc0000135
Another quicker alternative way to test this (YMMV) was to compare the output with another build config that does work. In our case, we can run release builds just fine, but debug builds barf. And the release output showed vccorlib140_app.dll loaded while the debug had it missing.

Instant Run - It keeps saying a class has been added when there is none

I've updated my Android Studio setup to 2.0-beta2 release in order to have a taste on the new Instant Run feature.
I've followed all instructions available including updating Gradle plugin to 2.0.0-beta2 and such but alas, I still can't get IR to run.
That message appears all the time I want to run my app using IR. The main caveat here that I did not add any new class to my code base; not even one. All I did before running that build was changing 2 lines within one of my custom View class from this:
subView1.setVisibility(View.GONE);
subView2.setVisibility(View.GONE);
..to this:
subView1.setVisibility(View.VISIBLE);
subView2.setVisibility(View.VISIBLE);
Despite that fact I still can't get IR to run.
Any clues on what's happening here?

issue appears only in generated app.exe and dont appear in the sources' execution | PowerBuilder

I have an issue when i execute my app.exe, there is an error which is revealed only in the ".exe", if i try todo the same thing when i use the sources, there is no problem, i think the problem is when there is a call of the update method from a datastore, it return -1 with generated .exe and 0 when i execute sources.
i have tried to refresh any library from my app, before building, but the issue remains, for information the app is using a DB2 DATABASE, and it is built and run in a windows7 environment.
The likely cause is that when you built the exe, the DataWindow object assigned to the DataStore wasn't included. You need to use a .pbr file in the Project object. Look in the help file under 'deploying your application'.
I have encountered this problem as well when I deployed strictly to a *.exe file. The problem went away when I deployed to a *.exe with a *.pbd. This is established on the "libraries" tab of your project by checking the pbd checkbox.
An 'exe' only deployment can't handle hard coded 'literal strings' in your code. Creating and deploying 'pbd' library will allow 'literal strings'.

Building with code contracts on AppHarbor

I'm trying to deploy my first AppHarbor-hosted app and have run into a problem with my build. Everything builds fine until the code contracts try to rewrite the assemblies. The error in the log is:
CodeContractsRunCodeAnalysisInternal:
CodeContracts: Task manager is unavailable (unable to run in background).
CodeContracts: ABC: Run static contract analysis.
CodeContracts: ABC: Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'System.Data.SqlServerCe, Version=3.5.1.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' or one of its dependencies. The system cannot find the file specified.
CodeContracts: ABC: at Microsoft.Research.CodeAnalysis.SQLCacheDataAccessor.GetMetadataOrNull(String key, Boolean silent)
CodeContracts: ABC: at Microsoft.Research.CodeAnalysis.CacheManager`11.TestCache()
CodeContracts: ABC: at Microsoft.Research.CodeAnalysis.CacheManager`11..ctor(Dictionary`2 methodAnalyses, Dictionary`2 classAnalyses, GeneralOptions options)
CodeContracts: ABC: at Microsoft.Research.CodeAnalysis.CacheManager`11.Create(Dictionary`2 dictionary, Dictionary`2 dictionary_2, GeneralOptions generalOptions)
CodeContracts: ABC: at Microsoft.Research.CodeAnalysis.Clousot.TypeBinder`9..ctor(String[] args, IDecodeMetaData`9 mdDecoder, IDecodeContracts`5 contractDecoder, IDictionary assemblyCache, Action`3 setTargetPlatform, IOutputFullResultsFactory`2 externalOutputFactory)
CodeContracts: ABC: at Microsoft.Research.CodeAnalysis.Clousot.ClousotMain[Local,Parameter,Method,Field,Property,Event,Type,Attribute,Assembly](String[] args, IDecodeMetaData`9 mdDecoder, IDecodeContracts`5 contractDecoder, IDictionary assemblyCache, Action`3 setTargetPlatform)
CodeContracts: ABC: at Microsoft.Research.CodeAnalysis.CCI1Driver.Main(String[] args)
CodeContracts: ABC:
CodeContracts: ABC: Static contract analysis done.
I know that when building locally with Visual Studio that the code contract stuff runs in a background thread. Maybe AppHarbor does not allow such threads to be created to do this? But what is this error about System.Data.SqlServerCe.dll missing? My code sure doesn't use it but maybe the MS code contracts do?
Just wondering if anyone has successfully deployed code that has code contracts in it to AppHarbor and if so what did you do to make it work? It may be that SQL Server CE will need to be installed by AppHarbor in order for code contracts to work. Oh, and my build does not build the code contract reference assembly, it just tries to do the static checking and do the rewriting to get the run-time checks done.
Lastly, I did try disabling the code contracts from the AppHarbor.sln but that setting is a project setting and not a solution setting so it disables them for my regular solution file too.
Figured it out. The .NET Code Contracts (the System.Diagnostics.Contracts namespace, for those who don't know) has a feature that can do static analysis of the code based on the contracts that have been put into the code. If you have the Visual Studio add-on for code contracts installed you can go to a VS project's property pages and click the Code Contract tab. In the Static Checking section there is an option called Cache Results. If you enable this then the static checking uses a SQL Server embedded database at build time to make whatever it does for its static code analysis run faster (apparently this file will persist in your project directory between compiles). This is a dependency that a build server has on SQL CE, it has nothing to do with the run-time environment for the app.
Since AppHarbor does not have SQL CE on their build servers what I've done is to change each of my projects' Code Contracts properties to do Perform Runtime Contract Checking and Perform Static Contract Checking for both Debug and Release builds, but for the Release build the Cache Results option in the Perform Static Contract Checking section is disabled. (Note also that since AppHarbor doesn't allow background tasks to run from Visual Studio that the Check in Background option on the Perform Static Contract Checking section must also be disabled.)
Why does it seem like I'm the only one that uses the System.Diagnostics.Contracts namespace (other than the .NET Framework itself)?
I'm not very familiar with Code Contracts, but the problem may simply be that you're missing SQL Server CE. You might want to try a project that's not using SQL Server CE just to check. Consider adding SQL Server CE using NuGet or as a bin-deployable assembly to ensure it's available when AppHarbor runs your build. There's more info in this blog post.
Although every error message that Code Contracts produces suggests that you need to install SQL Server CE 3.5.1, you really have to install version 3.5.2.
Uninstalling all other 3.5.x versions of SQL Server CE and installing this got things working for me. And yes, you really do need both the 32 and 64 bit versions if you are on a 64-bit machine.

How to have just ONE instance running of an exe with 3.5 .NET framework and CE windows 5.0

I've searched long and hard for an answer to my question and have found answers only to a class that does not exist in the 3.5 .NET frameworks version (and with CE Windows 5.0.) Also, it's Visual C# with Visual Studio 2008.
When I try the following (using System.Threading)
bool ok;
Mutex myMutex = new Mutex();
ok = Mutex(true,"scanner", out ok);
The compiler complains that the Mutex is a type, but used as a variable. If I use a [STAThread], it also complains that it can't find it and I"m forced to use [MTAThread].
Are the classes for the mobile device type of c# programs the same for console based ones? I'm somewhat new to this and the idea of how to declare, use, lock and everything you wanted to know about a mutex is making my head sore. O.o I suspect it's because the classes are different from the console verseions and the mobile versions.
It seems so simple, create a mutex, check for it's existance, if so then don't start a new exe instance. That is all I want...just run one instance of any exe. This is a mobile device thus it's a standalone and I never have to worry about anyone else using the .exe. Just need to stop the user from tapping the start button 15 times and having 15 instances of the application running (then complain about low memory usage!)
I've read that a good way is to create a thread, lock it then check if the lock was successful to test if an instance of an exe is already running, close it if so else run the exe. Is there an easier way to do this?
One way to approach this would be to open a file for writing. Only one instance of the application could obtain this lock at a time. On startup, try and obtain a file handle for writing, if it fails, there must be another instance already running: exit immediately.
I think you can forget mutexes since we are talking about separate proceses here.

Resources