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.
Related
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.
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?
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'.
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.
I have written a sequential workflow in SharePoint on our development environment. After testing, we decided to deploy this workflow as a feature on the staging environment. We did the following:
copied the strongly named assembly to the GAC using gacutil
copied feature.xml and workflow.xml to WebServerExtensions/12/templates/features/someFolder
installed feature (stsadm command)
activated feature (stsadm command)
All worked exactly as planned and the workflow behaved correctly. The problem was, we decided to change something in the code (a message was not very self explanatory), so on the development machine we updated the message as requested and rebuilt the project.
The problem is, we cannot seem to find a way to correctly get rid of the previous version of this workflow/feature.
To deploy the upgrade, we:
deactivated and uninstalled the feature (stsadm commands), removed also from GAC.
increased the version of the assembly
performed steps 1 to 4 from above.
When using the workflow we are still getting the first message, we cannot find a way to get the new message to be displayed.
What are we missing?
All the workflow logic "lives" inside the code assembly you are running. This means you can delete the old version of DLL (don't change assembly version numbers, use AssemblyFileVersion instead) from the GAC and replace it with the new version.
Be aware, though, that if you have changed the workflow in the designer, running instances of the old workflow version will "freeze" and never finish. Ask your users to finish their running WF-s before you upgrade the code.
It seems that the problem was in the Workflow.xml file.
Because I incremented the AssemblyFileVersion, and only replacing the dll in GAC did not work, I checked the two xml files: Feature and Workflow to see which one did not recognize the new dll (if the case). The workflow.xml file had a reference to the old version in it. I updated that, installed and activated the feature again, and it is working perfectly now.
Thanks for your support!