D3DERR_INVALIDCALL error, TeamCity builder - c#

I've been trying to use TeamCity 4.5 in order to automate builds of an XNA project but I have a small problem. My projects compile correctly under Visual Studio 2008, but not when compiled with TeamCity as the builder. The configuration file uses the sln2008 setting, and compiling goes well for a while, but as soon as it goes compiling .png textures to .xnb, I get the following error:
[11:28:41]: [Project "Content.contentproj" (default targets):] Content\head.png Building content threw InvalidOperationException: D3DERR_INVALIDCALL
at Microsoft.Xna.Framework.Content.Pipeline.CommonHelperFunctions.InitD3D()
at Microsoft.Xna.Framework.Content.Pipeline.TextureImporter.InitD3D()
at Microsoft.Xna.Framework.Content.Pipeline.TextureImporter.Import(String filename, ContentImporterContext context)
at Microsoft.Xna.Framework.Content.Pipeline.ContentImporter`1.Microsoft.Xna.Framework.Content.Pipeline.IContentImporter.Import(String filename, ContentImporterContext context)
at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.ImportAssetDirectly(BuildItem item, String importerName)
at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.ImportAsset(BuildItem item)
at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.BuildAssetWorker(BuildItem item)
at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.BuildAsset(BuildItem item)
at Microsoft.Xna.Framework.Content.Pipeline.BuildCoordinator.RunTheBuild()
at Microsoft.Xna.Framework.Content.Pipeline.Tasks.BuildContent.RemoteProxy.RunTheBuild(BuildCoordinatorSettings settings, TimestampCache timestampCache, ITaskItem[] sourceAssets, String[]& outputContent, String[]& rebuiltContent, String[]& intermediates, Dictionary`2& dependencyTimestamps, KeyValuePair`2[]& warnings)
Inner exception: COMException: Exception from HRESULT: 0x8876086C
I do not have any ideas what is causing this. Like I said, it's able to compile .fbx models correctly as well as my ContentPipeline project and my SharedContent project (part of the solution).
What I would actually like is some pointers to what would be the source of the problem (and if possible, a solution to the problem). As far as I understand, there seems to be a problem with the D3D library. I will also remind you that this whole solution compiles under Visual Studio 2008, thus there is a small problem with TeamCity, either I haven't provided something, or something is actually incorrectly set.

Almost certainly, Team City is running it's build process as Local System in a non-interactive mode, and not as a user that actually has the access and ability to grab the graphics device. I know I've had problems even attempting to batch process textures through a Remote Desktop interface because DirectX can't grab the graphics device.
The solution may be to see if Team City offers you the ability to request that it's builder run as a logged on user, not as Local System, or as a service, though I can't tell you that that's actually even possible in Team City.

I don't have a solution but I've been thinking about it.
The error is D3DERR_INVALIDCALL so I'm thinking the device isn't available at that time for some reason.
1) Do the machines running the build have DirectX installed/a graphics card? I'm assuming yes since XNA requires a card with shaders but TeamCity is a build distribution so maybe it's running on a machine without it?
2) Maybe TeamCity is causing too too many Direct3D devices to be created on the same machine/process (complete guess)?
Do the model files that compile correctly use textures or are they just geometry data? I have a feeling the content builder doesn't need access to DirectX to build models but does for texture data. Can you build anything else that requires access Direct3D? Can you build a project using TeamCity that just has one texture in it's content folder?
I'm not sure if this would work but can you get more information by running DirectX in Debug Mode and looking at the output?
Hope this helps somewhat.

XNA and DirectX 9 require a current logged in user in order to compile the Content folder.
The solution is simple, set up a build agent machine (real physical machine) with the pre-reqs for XNA (VS2008, XNA Game Studio 3.0, etc) and make it log in on startup, then create a script to run the team server agent when logged in (by placing a shortcut to the agent run script in the start up folder in the start menu).
This way the agent will run as the local user and can build as normal.
I have done this and can confirm that it works.

Sorry to drag up an old thread but I've just run into the exact same problem trying to get TC to build my XNA project on Windows Server and wanted to help others coming across the same problem.
I've just found this article and blog which looks like a very promising solution:
http://forums.create.msdn.com/forums/p/86699/532976.aspx
&
http://blogs.msdn.com/b/astebner/archive/2011/07/07/10184338.aspx
Aaron basically states that the new beta of Win Phone SDK 7.1 Beta 2 contains XNA Game Studio 4.0 Refresh Beta 2 which now allows you to build content via the content pipeline in the following types of configurations:
If your screen is locked during a build
If you are running a build on a headless computer
If you are running a build from a non-interactive user account
But it looks like it'll only run on Vista or above - hopefully that should include servers too. Update: Nope sadly it wont install on my Windows Server :(

Related

Select .app Files in MacOS File Browser using C#/DotNet

I'm working on a MacOS application built in Unity3D. I'm using a native file browser plugin to open native MacOS file dialogs for selecting files.
In order to generate PDFs, my app relies on using Chromium's Headless/command line functionality.
On Windows, I can easily get the path to the included Microsoft Edge as that's standard, but on Mac, unless I guess and check (which I already do), there isn't a way to guarantee a Mac user has a Chromium-based browser installed.
So I intend on allowing the user to set the path manually by selecting the .app file with a file dialog. But even when I specify .app to be a valid extension, they still don't appear selectable.
I assume this is some sort of MacOS-specific limitation or default permissions, though I can't find much info on this online.
Using C#/DotNet s there any way of allowing this behavior as needed?
For some more info: I'm just running the application using System.Diagnostics.Process.Start() with command line arguments.
Based on my experiments searching for Google Chrome (though Edge or Opera are just as usable), the path I'm looking for is:
/Applications/ {{APP NAME}}.app/Contents/MacOS/{{APP NAME}}
Because Contents isn't accessible by most users, I figured I would just automatically go in and grab the binary with the correct name.
I know I could include some lightweight version of ChromeDriver with my app, but I'd rather keep everything as self-contained as possible, especially as so many people already have Chrome (or Opera, Edge, etc) installed. The challenge is that not everyone has it installed in the same place, hence my need to make it customizable.
Any ideas or help would be appreciated!
Thanks!
After doing some testing: It seems that this limitation is only when running inside the Unity Editor. Once the app is built into a standalone Mac application, the file dialog does allow the selection of .app files and it works as expected.
Not a 100% solution to this problem, but definitely clears up some concerns.

Could not load file or assembly.. Even though its there in the proper location and builds fine

I have a predominantly managed c# .net 4.6 app that is trying to call into a c++ dll (that is also built as part of the solution), Visual Studio 2017.
I get this exception:
"System.IO.FileNotFoundException: 'Could not load file or assembly 'XXX.dll' or one of its dependencies. The specified module could not be found.'"
There doesn't appear to be any more information. The dll is in our binaries directory with all our other dlls that load fine, and the exe that is being run in the debugging session (The start up project).
I've checked the solution configuration manager, its building the dll as x64 in our Debug|Any CPU config, which makes sense.
No one else in the office has this issue, and I didn't have this issue on my old computer (I'm getting now trying to set up my new dev computer, which is the exact same specs as the old one) Windows 10.
I have the WindowsSDK 8.1 and 10 installed, and the vs c++ redistributes.
Any Ideas? Or atleast, and idea how I can get more info about whats actually going wrong? (This exception is frustratingly vague).
You’d want to use Fuslogvw.exe, the assembly binding log viewer. It can be started by launching the Developer Command Prompt for VS. The first thing is to enable logging, and the simplest way is to run as administrator (as a comment to an answer here correctly points out); you can alternatively set the ForceLog regkey specified here if running as a regular user account.
There's also a small video I did a while back to test how this works. You can find this in this article. Just scroll to the bottom, it's within the 2nd question starting from the end.
If that doesn't work, run Process Monitor and set a filter for your specific .dll and see what the CLR does in detail when searching for it.

Android app debugs for a few seconds then just stops

I'm trying to set up a new Android app development environment at home and I've run into a problem that is a showstopper.
First, here is my environment:
Windows 10
Visual Studio Community 2015 with Xamarin platform installed
Test device is: G Pad 7.0 LTE
Android Version 5.0.2
I'm following this tutorial: MSDN tutorial
When I go to debug my test app, here is what happens.
Select debug from Visual Studio with my tablet as the target
VS deploys to the tablet
App starts on the tablet
App and debug session runs for about 5-10 seconds.
Debug session ends and app closes
No errors are displayed in Visual Studio and when i turn on Android logging it's a such a massive overflow of information that I don't really know where to begin searching for a problem.
Please also note that when I first set up the app, according to the tutorial, debugging on the tablet worked fine. The initial build is simply a template with a few basic controls.
In between then and when it stopped working I also added and successfully tested a Windows Phone project on a Windows Phone device.
Once I got to the section where I was modifying the project is when the problem started. I thought that perhaps a change in the code I did caused this issue so I tried another blank app and that blank app now crashes as well.
When I deploy the tutorial app to an emulator it crashes immediately but when I deploy a blank app it doesn't crash.
I also tried restoring the tablet to factory defaults and testing again. Same scenario: Blank app and tutorial app run for a few seconds, debugging stops, app closes.
Any clue as to what type of problem I'm looking at?
Solution
Clean your project (Right-Click on Project and select clean)
Go to your build folder. Probably in your Android project's root folder, named "obj". Delete either build you had, when you ran into this behavior (Debug or Release).
Directory Path
./AndroidProject/obj/Debug
./AndroidProject/obj/Release
Restart Visual Studio
Build and run again and it should work just fine, as the md5-hashes are now matching again.
I had also uninstalled the app before from the device and restarted it, I don't know whether this is required anymore, because the app is now being "reinstalled" by newer Xamarin versions anyway.
adb uninstall com.your.domain
Story and Background information
Have had the same issue with a device running Android 5.0.
Basically, the app was just stopping without any note.
When I now restarted the phone, The log was extended (once) by the following line:
Device could not find component named: *com.your.domain*/{*md5hash*}.*{Activity}
It turns out that with Andrpod 5.0 a hashing mechanism was implemented:
With the 5.0 release, the default package names for Android Callable
Wrappers will be based on the MD5SUM of the assembly-qualified name of
the type being exported. This allows the same fully-qualified name to
be provided from two different assemblies and not get a packaging
error.
See this for further information Xamarin.Android 5.1
So, if the md5-hash now changes from time to time, a simple Clean of your project is not enough.
I ran into this same issue and applied the same solution described above many times, which seemed to remedy this particular problem.
A possibly related fix, but definitely worthwhile note
After releasing this Android app and later releasing updates to the app, we got feedback from users that their Android Home screen shortcut to the app was disappearing after each app update. This is not good, for obvious reasons, but the fix for it was very simple as noted here:
dream-team-mobile-blog - Android app removes shortcut on update Xamarin solution
On the main activity, set a Name attribute of
<your package>.<your main activity>
like:
com.mycompany.myapp.MainActivity
For my solution, I chose to do it in code like this:
[Activity(Name = Constants.PackageName + "." + nameof(MainActivity),
Label = Constants.AppIconTitle, Icon = "#drawable/icon",
Theme = "#style/splashscreen", MainLauncher = true,
LaunchMode = LaunchMode.SingleInstance,
ConfigurationChanges = ConfigChanges.ScreenSize | ConfigChanges.Orientation)]
//Side Note: I change my PackageName between Prod and SQA builds, so using
//a constant as seen above makes that change less risky to miss maintaining.
//Also, using nameof() keeps things tight and a sure match.
public class MainActivity : global::Xamarin.Forms.Platform.Android.FormsAppCompatActivity
I mention it here in this post because, having this fix in place may have:
definitely prevented app shortcut loss and
possibly prevented the issue discussed in this post
as the MD5 hash prefix from the Main activity seems to no longer be generated.
This tweak may fix two bugs with one fix. If not, implementing a fixed main Activity Name will surely help your users keep their shortcut to your app when you release updates!
What fixed it for me in Visual Studio 2017 is going to :
Tools → Options → Xamarin → Android Settings
and uncheck:
Preserve Application data cache on device between deploys
go to your AndroidManifest.xml and change your package name.

WebSupergoo.ABCpdf Test application does not work

I recently cleaned up my Windows 7 64-bit PC, and after it ABCpdf8 started giving me an error, when I try to export HTML to PDF.
The error is "Failed to initiate IE compatibility mode: Failed to load all required assemblies."
at WebSupergoo.ABCpdf8.Internal.IECompatibility.Activate()
at line
theID = theDoc.AddImageUrl(input.Text);
of the test application, and I have no idea why, because I did not remove any assemblies from my machine.
If I run the compiled application on another workstation with the same config (Windows 7 64-bit), it works fine. Dependency Walker images showed no difference in DLLs sets from my machine and from another.
How else can I identify the source of the problem?
It is definitely neither a missing DLL, nor the user access to the system folders, because, I checked user rights as well, they're identical on both machines.
I assume that it might be a corrupted registry entry. Is there any way to quickly check the assumption?
It has to be said that, ABCpdf comes as third-party tool within another software, so I cannot contact support directly, but through the main vendor.
I had a similar problem with different behavior on w7 and ws2008, which was solved by using the Gecko engine
doc.HtmlOptions.Engine = EngineType.Gecko;
Note that websupergoo recommends using Gecko rather than IE9 as parts of the IE API it uses have been deprecated. (item 6.29)
When you 'cleaned' your system you may have erased the license key from the registry. Try re-installing your 'other software'.

Touchless Vision C# webcam wrapper, can't run without VS installed

So I've been hunting around for a good way to utilize a webcam from within a C# application. I tried a p/invoke dll which turned out to be inexplicably and irreproduceably buggy. After tinkering with a few others that either weren't suitable or were utterly archaic, I was referred to this:
http://jakemdrew.wordpress.com/2012/01/10/controlling-your-web-camera-using-c/#comment-15
It's the Touchless Vision code with a C# wrapper updated to work in VS 2010. It works wonderfully...as long as VS is installed on the machine. Download and run that release build on anything that doesn't and it will throw an error claiming that it can't find WebCamLib.dll or one of its dependencies. The fun part is that I've already integrated this into the project. It works great, but I'd like to be able to distribute this without additional installers or requiring VS 2010 to be installed on everything. What gives here?
I am using Aforge.net libraries(Aforge.net) without any problems on multiple computers even without VS installed.
But are you sure WebCamLib.dll is copied in the app directory? Aforge.Net also needs some dlls copied to computers, but if you have set Copy Local property to true, it should be inside the Debug/Release directory, also it will be in the directory when you release your app using Publish.
Sample:
Add Aforge.Controls.dll to your toolbox items
In designer put VideoSourcePlayer control in your form
Add private FilterInfoCollection videoDevices; in form class
Add into form initializer (or in function that you want to start your camera)
videoDevices = new FilterInfoCollection(FilterCategory.VideoInputDevice);
foreach (FilterInfo fi in videoDevices)
{
this.videoSourcePlayer1.VideoSource = new VideoCaptureDevice(MonikerString);
this.videoSourcePlayer1.Start();
break;
}
Now you should be getting image from webcam in VideoSourcePlayer control. You can use NewFrame event of VideoSourcePlayer control to get access to each frame camera is sending and to save or change image.
well some time has passed since the question but, just for the sake of solving it I´ll say this:
Supposing that you have the references to the dlls and the files where they should be the only thing left to do is check the dll dependencies, in this case
the programmer of the touchless and webcamlib dlls didn´t care much for "versioning" so, find the c++ vs2012 redistribution for x64 and x86 and install them, then run your App and carry on with your Project.

Categories