This project is read-only.

V8Engine Failing To Load

Oct 31, 2014 at 10:24 PM
First, implementing your V8Engine on my project has allowed me to create a pretty sweet dynamic review service for my company. So, thank you.

Now, while I've been able to load and work with V8.NET, it seems that each day when I first start it up I run into the InvalidOperationException, Failed to load...
The temp \x64\V8.Net.Proxy.Interface.x64.dll keeps disappearing and then failing to generate.

Every day this week I've had to rebuild, run/debug, then manually copy over the x64 & x86 folders into the 'Temporary ASP.NET Files' subfolder where the V8 dlls are being dropped.

The V8.Net.DLL is making it into the folder successfully, but not the rest.

Any ideas?
Oct 31, 2014 at 10:45 PM
Edited Oct 31, 2014 at 10:46 PM
I don't think I'm following, because "starting up" to me means you are running your app, and the files start moving on their own. ;) What exactly is your setup, folder structure, etc.? Do you mean each time you open your IDE to develop, that files disappear, or only after a build? If you have the project opened in Visual Studio, take a look at the build events for each project to see if you need to modify something.

BTW: Glad to hear it's working for your project. ;) Thanks.
Nov 3, 2014 at 6:25 PM
Sorry for my lack of clarity, but thanks very much for your quick reply.

The x64 & x86 folders are being cleared from where your dlls are being created/stored ("C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files...\dl3\5d492405\ce18dd13_69fcce01\") after a period of inactivity (e.g. mostly over night, but also if I just have a long meeting and come back to my desk).

When I then go and run my app in debug to test, etc, I get the aforementioned error (by the way, we use Visual Studio 2013 + TFS).

To fix it, I have to clean the solution, rebuild (I then usually get a w3wp.exe debug error...), start debug, and copy over the x64 & x86 folders from the project folder where they live to the temp folder above. Then I'm good until I'm idle for too long again.


Below are pertinent lines from the build output:
  • 'w3wp.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\services_billing_billreview\66e25b4e\ebc0b451\assembly\dl3\5d492405\ce18dd13_69fcce01\V8.Net.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
  • 'w3wp.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\services_billing_billreview\66e25b4e\ebc0b451\assembly\dl3\e8a0c5c6\b63bdf13_69fcce01\V8.Net.SharedTypes.dll', Skipped loading symbols. Module is optimized and the debugger option 'Just My Code' is enabled.
  • 'w3wp.exe' (Managed (v4.0.30319)): Loaded 'Anonymously Hosted DynamicMethods Assembly'
  • 'w3wp.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\services_billing_billreview\66e25b4e\ebc0b451\assembly\dl3\5d492405\ce18dd13_69fcce01\x64\V8.Net.Proxy.Interface.x64.dll', Symbols loaded.
  • The thread '<No Name>' (0x2a08) has exited with code 0 (0x0).
  • The thread '<No Name>' (0x24c0) has exited with code 0 (0x0).
  • A first chance exception of type 'Microsoft.CSharp.RuntimeBinder.RuntimeBinderException' occurred in Unknown Module.
  • 'w3wp.exe' (Managed (v4.0.30319)): Loaded 'C:\Windows\assembly\GAC_MSIL\Microsoft.VisualStudio.Debugger.Runtime\12.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.Debugger.Runtime.dll'
  • The program '[3040] w3wp.exe: Managed (v4.0.30319)' has exited with code 0 (0x0).
Nov 3, 2014 at 7:44 PM
Why are the DLLs in that folder? That’s a temporary folder, and my guess is it gets cleaned out by VS at idle time. Should it not be compiling to a project bin directory and running from there? I’d need more details on how your project is setup. If you can, zip your project to dropbox or onedrive (or whatever) and send me the link. I’d be glad to take a closer look.
Nov 3, 2014 at 8:26 PM
To be honest, I'm not really sure why they are being placed/running there. Perhaps it is related to IIS?
Some of the V8 dlls are populating in my projects bin, but 'AssemblyInfo.ini' , 'V8.Net.DLL', and 'V8.Net.PDB' are appearing in the temp folder, and it is looking for your x64 folder there.

An unrelated question:
For my project, I'm loading up a large JSON object into the handle when I instantiate the engine, and then accessing that object via a series of JavaScript snippets that run in parallel and all need to return an object containing a bool and a string.
However, I've been unable to get anything back into the C# context besides a string that says 'object object'.
What steps am I missing?
Nov 3, 2014 at 9:28 PM
Ah, you have a web project? Are you trying to run it server side as a web service of sorts?

Regarding the JSON object, I'd need to know more details about your "series" of code to know more.
Nov 3, 2014 at 9:44 PM
Yes, it's a web service, MVC style in our own framework.

The snippet I'm testing now is below:
var runDate = new Date(txBillData.RunDate);

var reviewItem = {
    IsFlagged: false,
    Note: """"
};                                                              

reviewItem.IsFlagged = txBillData.Adjustments.some(function(adjustment) {
    return (new Date(adjustment.EnteredDate) <= runDate && adjustment.Billed === 0);
});
reviewItem.Note = """";
reviewItem;";
reviewItem populates correctly, and if I view the dynamic results in C# from
var reviewResult = billReviewHandle.Engine.Execute( adjustmentMissingFromInvoiceReviewJS )
IsFlagged and Note are present. When I attempt to assign it to a variable, however, I just get the string "[object Object]"
Nov 3, 2014 at 10:15 PM
I need to see THAT step, where you are assigning it. lol :)
Nov 3, 2014 at 10:20 PM
BTW: I have this code in the assembly resolver:
                try
                {
                    return Assembly.LoadFile(fileName);
                }
                catch (Exception ex)
                {
                    var msg = "Failed to load '" + fileName + "'.  V8.NET is running in the '" + bitStr + "' mode.  Some areas to check: \r\n"
                        + "1. The VC++ 2012 redistributable libraries are included, but if missing  for some reason, download and install from the Microsoft Site.\r\n"
                        + "2. Did you download the DLLs from a ZIP file? If done so on Windows, you must open the file properties of the zip file and 'Unblock' it before extracting the files.\r\n"
                        ;
                    if (HttpContext.Current != null)
                        msg += "3. Make sure the path '" + assemblyRoot + "' is accessible to the application pool identity (usually Read & Execute for 'IIS_IUSRS', or a similar user/group)";
                    else
                        msg += "3. Make sure the path '" + assemblyRoot + "' is accessible to the application for loading the required libraries.";
                    throw new InvalidOperationException(msg + "\r\n", ex);
                }
Did you not get this error message? Did you give the assembly root location in the message the proper rights for the app pool id to access it?
Nov 3, 2014 at 10:27 PM
Edited Nov 3, 2014 at 10:27 PM
Just to add: In you case, I think this line is running:
assemblyRoot = HttpContext.Current.Server.MapPath("~/bin");
So it's loading from wherever that resolves to. You can try running "HttpContext.Current.Server.MapPath("~/bin")" in your code to see where that is. If the IIS server shuts down after some idle time, it may refresh everything in "temp" upon starting up again, or after another build/run. Unfortunately I never had this issue, so I'm unsure as to why your project setup is behaving this way. You might try setting up IIS for your project instead, and make sure that a visual studio maps a virtual folder to your PROJECT folder, and not the temp one.
Nov 3, 2014 at 10:37 PM
If you are using and wish to keep using the built-in VS IISExpress, then you may also wish to add a post-build event to copy the V8.NET dlls to the output target each time you build/run the project, since it may only be copying and maintaining the root DLLs you are referencing.
Nov 6, 2014 at 5:37 PM
Well, I was able to get my object out of the handle by switching it around to this:
                Handle reviewHandle = billReviewHandle.Engine.Execute( adjustmentMissingFromInvoiceReviewJS );

                dynamic reviewResult = v8Engine.GetObject( reviewHandle );
Also, I found some inconsistencies in the project file that seemed to be mixing up the .NET 4.0 and 3.5 references. I just deleted the .NET 3.5 stuff entirely, and it started working normally. I don't really know why/how it was manifesting as that error, but hurrah for working now.
Nov 6, 2014 at 8:07 PM
Edited Nov 6, 2014 at 8:09 PM
Oh ok, perhaps I misunderstood what you where trying to do. Glad it works.

There are no inconsistencies in the solution as is, unless it was modified. The solution compiles the 3.5 project to one folder, and 4.0 to another. To this end, they also use different BIN and OBJ folders to prevent conflicts as set in the project settings (so if you don't separate them, then that's why). My local setup works perfect. Perhaps your project was picking up the wrong libraries, and removing them somehow allows it to use the 4.0 ones...? Anyhow, glad it's working. ;)
Nov 6, 2014 at 8:14 PM
In regards to "adjustmentMissingFromInvoiceReviewJS", your handle "reviewResult" is a handle to your object. Of course, if you set that to a variable you may get the string result of "[object Object]", if the compiler has determined to use the string conversion. You are supposed to operate on that object, such as reviewResult.getProperty("Note"). When you said "it" in your post, I thought you meant assign "Note" to a variable, so you weren't clear. ;)
Nov 6, 2014 at 8:15 PM
Edited Nov 6, 2014 at 8:18 PM
OH, sorry, one more thing. You need to simply cast your handle to ObjectHandle, then you have access to the methods to need. lol. Forgot about that. ;)
ObjectHandle reviewHandle = billReviewHandle.Engine.Execute( adjustmentMissingFromInvoiceReviewJS);
Don't use "v8Engine.GetObject()" unless you need/want a generic CLR object to work with instead of a handle.
Nov 19, 2014 at 9:24 PM
So, suddenly, my error is magically back.
Magic, because no changes were made to the implementation, but running it today suddenly once again results in:
Failed to load 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\services_billing_billreview\66e25b4e\ebc0b451\assembly\dl3\5d492405\ce18dd13_69fcce01\x64\V8.Net.Proxy.Interface.x64.dll'. V8.NET is running in the 'x64' mode. Some areas to check:
  1. The VC++ 2012 redistributable libraries are included, but if missing for some reason, download and install from the Microsoft Site.
  2. Did you download the DLLs from a ZIP file? If done so on Windows, you must open the file properties of the zip file and 'Unblock' it before extracting the files.
  3. Make sure the path 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\services_billing_billreview\66e25b4e\ebc0b451\assembly\dl3\5d492405\ce18dd13_69fcce01' is accessible to the application for loading the required libraries.
This occurs when hitting this line:
var v8Engine = new V8Engine();
My references look correct as far as I can tell, I've previously installed the VC++ 2012 redistributable libraries, I followed the instructions in 2 originally, and the path in 3 at least seems accessible, though my company's ServiceDesk handling of permissions policies are known to be questionable.

Thoughts?
Nov 19, 2014 at 10:50 PM
Without access to the project I can only guess. Some things to check:
  1. What security profile is the app running under? If not already, try launching VS as admin and see if that works.
  2. Open the path and confirm that the x64 directory exists, and all the x64 DLLs are there also (if any dll is missing it may fail as well).
It can only be a security issue, or missings files. You might want to setup IIS instead of relying on the built in VS IIS express so you have more control on how your project is running, and prevent DLLs from being "cleaned".
Dec 12, 2014 at 5:25 PM
Edited Dec 12, 2014 at 5:59 PM
The problem is that the dlls are being produced in Windows temporary directories.

This is now happening on our Integration server:
Error Message:
Failed to load 'C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\billing_billreview\eb115ac5\b287081c\assembly\dl3\99167f68\743e2c27_410fd001\x64\V8.Net.Proxy.Interface.x64.dll'. V8.NET is running in the 'x64' mode. Some areas to check: ...
Is there a way around this? I don't need the x86 option, so is there a way to eliminate the dynamic selection and just have it as straightforward dlls?

Can I send my project to you via email?
Dec 12, 2014 at 6:41 PM
Sure thing, I'd rather get to the bottom of this. ;)
Dec 16, 2014 at 10:44 PM
Edited Dec 16, 2014 at 10:46 PM
Hi Joshua,

When a web project is running, the DLLs in the ‘bin’ folder are shadow copied (http://goo.gl/vXbwGp). You have to make sure that all relevant DLLs are in the bin folder. Copy and paste everything in “Ambit.Services.Billing.BillReview\V8.NET v1.4.0.1\.NET 4.0” into the BIN folder. The DLLs should be shadow copied – however, I’m uncertain if sub folders are included. In the meantime I will create a test project to look into this further.

Thanks,
James
Jan 5, 2015 at 7:13 PM
I’ve found the following posts related to this issue:

Assembly CodeBase vs Location: http://blogs.msdn.com/b/suzcook/archive/2003/06/26/assembly-codebase-vs-assembly-location.aspx
Third party dll can't find its dependencies: http://stackoverflow.com/questions/6855924/third-part-dll-cant-find-its-dependencies-in-asp-net-mvc-project
Assemblies know their “copied from” location: http://stackoverflow.com/questions/2580833/asp-net-accessing-copied-content?rq=1

My guess is that, locally, and in call my tests so far, it works perfectly when running from VS (both IIS and IIS Express). The issue seems to be when deployed – perhaps not all libraries get copied (especially the native Google v8 dlls).

It’s interesting to note that my CodeBase path ({TheAssembly}.CodeBase value) points to the BIN folder of the test projects, BUT, the location path of the DLL ({TheAssembly}.Location value) points to the ASP.NET temp folder – and in that folder I have the exact same as you (v8.net.dll and v8.net.pbd). It also may be important for you to remember that V8.NET uses “HttpContext.Current.Server.MapPath("~/bin")” to find the DLLS in the “bin” folder of the IIS/IISExpress directory, and NOT the TEMP folder. You don’t need to have anything shadow copied, nor even worry about it. This of course fails if, for some reason, MapPath maps to the temp folder, which is not happening in any of my test cases so far.

So, next steps I guess would be to debug and check MapPath, and both CodeBase and Location values of the V8.NET assembly and find out why your setup of ASP.NET may not be respecting the CodeBase location – where the DLLs should be loaded from BEFORE the shadow copy. Again, I also only have one v8 dll in my temp asp folder, but it still works.

Example:
ASP.NET path to bin on server: HttpContext.Current.Server.MapPath("~/bin")
V8.NET Library CodeBase: Type.GetType("V8.Net.V8Engine, V8.Net").Assembly.CodeBase;
V8.NET Library Path: Type.GetType("V8.Net.V8Engine, V8.Net").Assembly.Location;

Let me know what your values are for those.

Also, I’ve updated the dev branch with the binaries that allow flattening the folder structure (all DLLs in one place for a single platform only [x86 or x64]).
Jan 6, 2015 at 10:39 PM
Failed at same point with new binaries. Thanks for trying though.


HttpContext.Current.Server.MapPath("~/bin") came back with a null reference error. I also tried HttpRuntime.AppDomainAppPath which was empty as well.

Type.GetType("V8.Net.V8Engine, V8.Net").Assembly.CodeBase =
file:///C:/Source/Ambit/INT/TMB/Billing/BillReview/Ambit.Services.Billing.BillReview/bin/V8.Net.DLL
Type.GetType("V8.Net.V8Engine, V8.Net").Assembly.Location =
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\services_billing_billreview\66e25b4e\ebc0b451\assembly\dl3\5d492405\00315974_4c29d001\V8.Net.dll
Jan 6, 2015 at 11:03 PM
Ah, this explains it. All ASP projects I tested had HttpContext.Current.Server.MapPath("~/bin") working perfectly fine, and thus was able to find the files. If it doesn't work, then it falls to another path via "Assembly.GetExecutingAssembly().Location", which is the TEMP path. I'm sure now if I change this to CodeBase, it will work for you. I wonder if this is the best course of action here. I'll look into it and post another fix today asap.
Jan 7, 2015 at 12:10 PM
Edited Jan 8, 2015 at 6:09 PM
OK! I've updated the development branch with more changes. As long as the V8.NET files (and sub folders) are copied correctly to the "bin" folder for the site, the libraries should be found correctly this time (in the pre-shadow copied location [most/all files in the ASP "temp" folder are shadow copies, and may not contain ALL libraries]).

I'm still unsure why there is no HTTP context value, as my default service project has it just fine. In any case, hopefully this change will settle any and all issues.
Jan 9, 2015 at 6:43 PM
James,
Thanks for working on this. Unfortunately, whatever you had changed in the previous version to put all the dlls into bin with a flat structure no longer seems to be working. The only V8 dlls populating in bin now are V8.Net.dll and V8.Net.SharedTypes.dll. The others aren't there at all; No .NET 4.0 folder or anything.

Same error.
Thanks.
Jan 9, 2015 at 6:53 PM
Edited Jan 9, 2015 at 7:37 PM
No DLLs get copied into the bin folder automatically. They are supposed to be copied by you manually and placed to the bin folder. Copy all of the V8.net files into the bin folder. I tried it and it works perfectly in my test project.

Copy the library's using the existing folder structure, don't flatten them.
Jan 9, 2015 at 7:01 PM
Oh yeah I forgot to mention there's a special way to handle this now. In the test Service project you should see comments at the top on how to integrate it properly. Open the service C-sharp file.

Jan 9, 2015 at 7:57 PM
Edited Jan 9, 2015 at 8:02 PM
I had comments in the service.svc.cs example explaining the integration, but forgot to mention it. A flat structure IS supported, and nothing has changed in that regard, You just need to know how it works. Consider this structure:
c:\MyProject\bin\V8.Net.dll
c:\MyProject\bin\V8.Net.SharedTypes.dll
c:\MyProject\bin\\x86\...
c:\MyProject\bin\\x64\...
In the above case, the resolver first looks for a V8.NET folder in the BIN directory, and if not found (which is the case here), then it assumes x86 and x64 folders are in the BIN folder, and looks for them. If the REQUIRED platform folder is missing (x86 for 32bit machines), then it assumes THEN that the interface assembly is local to the BIN folder.

ASP is now designed to work DIFFERENTLY. This is because you need to reference the DLLs in the project, and they may get shadow copied. As well, I wanted the natural content copy feature of visual studio to be used to allow VS to copy all OTHER DLLs into the BIN folder (so a build event is NOT required). Unfortunately there is no control over HOW VS copies the context (dll) files, so you will end up with this:
c:\MyProject\bin\V8.Net.dll
c:\MyProject\bin\V8.Net.SharedTypes.dll
c:\MyProject\bin\V8.NET\x86\...
c:\MyProject\bin\V8.NET\x64\...
Now you can see the problem. The BIN folder has the 2 DLLS (v8.net and v8.net.sharedtypes), copied because they are referenced by VS, BUT the V8.NET folder exists because the DLLs were copied as CONTENT. This is why I now look for a V8.NET folder in the BIN folder for the x86 and x64 folders.

All that said, you can still flatten the structure by copying all required files into the bin folder and removing any folders names "V8.NET", "x86", or "x64". If none of these folders are found, then "V8.Net.Proxy.Interface.dll" is loaded from the BIN folder, and will also expect the native DLLs to be there as well.

These are the comments I put in the service.svc.cs file:
/* V8.NET integration into ASP.NET:
 * 1. Create a project folder specifically named "V8.NET", or change the name using 'V8Engine.ASPBINSubFolderName'.
 * 2. For all DLLS in "x86" and "x64" under "$(ProjectDir)V8.NET", change "Copy to Output Directory" to "Copy if newer".  This should also tell Visual Studio that this
 *    content is required for the application.
 * 3. Set any DLLs that you have already referenced in the "$(ProjectDir)V8.NET" root folder to "Do not copy" - the build action will copy referenced DLLs by default.
 * 
 * When setup correctly, Visual Studio will replicate the folder structure for the DLLs in the "V8.NET" folder into the 'bin' folder, and the referenced DLLs will end
 * up in the root of the 'bin' folder.  Thus, you will have this folder structure:
 * - bin\V8.Net.dll
 * - bin\V8.Net.SharedTypes.dll (if referenced)
 * - bin\V8.Net\ (empty - no DLLs)
 * - bin\V8.Net\x86\*.dll
 * - bin\V8.Net\x64\*.dll
 * V8.Net.dll will look for the "V8.NET" folder in the 'bin' folder, and if found, will use that instead to locate dependent libraries.  If NOT found, it will expect
 * the 'x86' and 'x64' folders to be in the same folder as V8.Net.dll, as normal.
 * 
 * Note: ASP.NET may shadow copy some DLLs in the 'bin' folder (http://goo.gl/vXbwGp).  This means that those DLLs may end up elsewhere in a temporary folder
 * during runtime.
 */
Jan 9, 2015 at 8:09 PM
Edited Jan 9, 2015 at 8:10 PM
BTW: If you still have problems, then not all V8.NET DLLs are in the BIN folder, and you'll have to figure out why. There is no way to reference native DLLs in a project and have VS copy them, unless you add them as content, or create build events - this is the known nature of things within VS. So, step 1, you MUST make sure all DLLs (flattened or otherwise) are in the BIN folder for the project (perhaps copied as "content - copy if newer"). If there are only 2 DLLs there as you are claiming, then your project is not setup correctly. When you fix that part, the rest should work as expected. Placing the non-referenced DLLS into the bin folder is the developers responsibility to work out. V8.NET doesn't do anything magical in this regard.
Jan 19, 2015 at 5:48 PM
Feel free to let me know if you are still experiencing issues.
Jan 19, 2015 at 6:36 PM
I was having the same issue as before with the new dlls, but then I started trying to just put a check/copy for the temp folder into my app, and, at the very least, the error changed. I've had plans to continue testing and working with configuration, but I've been pulled away the last few weeks onto some other high priority projects. I'll be getting back to it as soon as I wrap this other stuff up.

Jan 19, 2015 at 8:56 PM
Hey no rush, just checking in. ;)
Jan 20, 2015 at 12:34 AM
Something to check out: http://stackoverflow.com/questions/24647396/asp-net-4-app-dll-is-shadow-copied-but-bin-dll-is-loaded-instead?noredirect=1#comment44425313_24647396

It seems I was using LoadFile instead of LoadFrom. Not sure if makes all the difference in this case (since the path should resolve correctly now), but in case it doesn't, LoadFrom is more suited to resolve the assembly file.

Note: This change is not included in the recent release - I just updated the dev branch now.
Mar 5, 2015 at 3:28 PM
Hey James,
Finally able to get back to this project.
I wiped the previous stuff, got the latest dlls from the dev branch, and followed your instructions closely, and it worked locally. I haven't had any problems on my machine. So, victory dance, sort of.
Unfortunately, after pushing it to our integration environment, I'm getting the 'Could not load file or assembly...' error. I checked the server, and the dlls were put into bin with the flat structure. I tried copying the V8.NET folder into bin as well, but to no avail.

Thoughts?


Stack trace, etc, are below:

Could not load file or assembly 'V8.Net.Proxy.Interface.x86' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.BadImageFormatException: Could not load file or assembly 'V8.Net.Proxy.Interface.x86' or one of its dependencies. An attempt was made to load a program with an incorrect format.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Assembly Load Trace: The following information can be helpful to determine why the assembly 'V8.Net.Proxy.Interface.x86' could not be loaded.

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Stack Trace:

[BadImageFormatException: Could not load file or assembly 'V8.Net.Proxy.Interface.x86' or one of its dependencies. An attempt was made to load a program with an incorrect format.]
   System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +0
   System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +210
   System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean forIntrospection) +242
   System.Reflection.RuntimeAssembly.InternalLoad(String assemblyString, Evidence assemblySecurity, StackCrawlMark& stackMark, Boolean forIntrospection) +17
   System.Reflection.Assembly.Load(String assemblyString) +35
   System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +122

[ConfigurationErrorsException: Could not load file or assembly 'V8.Net.Proxy.Interface.x86' or one of its dependencies. An attempt was made to load a program with an incorrect format.]
   System.Web.Configuration.CompilationSection.LoadAssemblyHelper(String assemblyName, Boolean starDirective) +12534692
   System.Web.Configuration.CompilationSection.LoadAllAssembliesFromAppDomainBinDirectory() +499
   System.Web.Configuration.AssemblyInfo.get_AssemblyInternal() +131
   System.Web.Compilation.BuildManager.GetReferencedAssemblies(CompilationSection compConfig) +331
   System.Web.Compilation.BuildManager.CallPreStartInitMethods(String preStartInitListPath, Boolean& isRefAssemblyLoaded) +148
   System.Web.Compilation.BuildManager.ExecutePreAppStart() +172
   System.Web.Hosting.HostingEnvironment.Initialize(ApplicationManager appManager, IApplicationHost appHost, IConfigMapPathFactory configMapPathFactory, HostingEnvironmentParameters hostingParameters, PolicyLevel policyLevel, Exception appDomainCreationException) +1151

[HttpException (0x80004005): Could not load file or assembly 'V8.Net.Proxy.Interface.x86' or one of its dependencies. An attempt was made to load a program with an incorrect format.]
   System.Web.HttpRuntime.FirstRequestInit(HttpContext context) +12656404
   System.Web.HttpRuntime.EnsureFirstRequestInit(HttpContext context) +159
   System.Web.HttpRuntime.ProcessRequestNotificationPrivate(IIS7WorkerRequest wr, HttpContext context) +12496021

Mar 5, 2015 at 9:29 PM
Edited Mar 5, 2015 at 9:30 PM
I see " System.BadImageFormatException". I'm thinking the bit depth is off somewhere, or something is being detected/loaded incorrectly somehow. If you are compiling using "any cpu" consider compiling to the target architecture of the server.
Mar 5, 2015 at 11:45 PM
Server is x64.
Switched project to explicit 64 bit.

Now getting this:

Server Error in '/Billing/BillReview' Application.

Could not load file or assembly 'file:///D:\Apps\Ambit.Services.Billing.BillReview\bin\V8_Net_Proxy_x64.dll' or one of its dependencies. The module was expected to contain an assembly manifest.

Description: An unhandled exception occurred during the execution of the current web request. Please review the stack trace for more information about the error and where it originated in the code.

Exception Details: System.BadImageFormatException: Could not load file or assembly 'file:///D:\Apps\Ambit.Services.Billing.BillReview\bin\V8_Net_Proxy_x64.dll' or one of its dependencies. The module was expected to contain an assembly manifest.

Source Error:

An unhandled exception was generated during the execution of the current web request. Information regarding the origin and location of the exception can be identified using the exception stack trace below.

Assembly Load Trace: The following information can be helpful to determine why the assembly 'file:///D:\Apps\Ambit.Services.Billing.BillReview\bin\V8_Net_Proxy_x64.dll' could not be loaded.

WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].

Stack Trace:

[BadImageFormatException: Could not load file or assembly 'file:///D:\Apps\Ambit.Services.Billing.BillReview\bin\V8_Net_Proxy_x64.dll' or one of its dependencies. The module was expected to contain an assembly manifest.]
   System.Reflection.RuntimeAssembly._nLoad(AssemblyName fileName, String codeBase, Evidence assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +0
   System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, IntPtr pPrivHostBinder, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +210
   System.Reflection.RuntimeAssembly.InternalLoadAssemblyName(AssemblyName assemblyRef, Evidence assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark& stackMark, Boolean throwOnFileNotFound, Boolean forIntrospection, Boolean suppressSecurityChecks) +44
   System.Reflection.RuntimeAssembly.InternalLoadFrom(String assemblyFile, Evidence securityEvidence, Byte[] hashValue, AssemblyHashAlgorithm hashAlgorithm, Boolean forIntrospection, Boolean suppressSecurityChecks, StackCrawlMark& stackMark) +155
   System.Reflection.Assembly.LoadFrom(String assemblyFile) +61
   Ambit.Configuration.Core.Providers.AutoloadAssembliesProvider..ctor() in d:\Workspaces\Frameworks\Ambit.Configuration.Core\Ambit.Configuration.Core\Providers\AutoloadAssembliesProvider.cs:42

[TargetInvocationException: Exception has been thrown by the target of an invocation.]
   System.RuntimeTypeHandle.CreateInstance(RuntimeType type, Boolean publicOnly, Boolean noCheck, Boolean& canBeCached, RuntimeMethodHandleInternal& ctor, Boolean& bNeedSecurityCheck) +0
   System.RuntimeType.CreateInstanceSlow(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) +159
   System.RuntimeType.CreateInstanceDefaultCtor(Boolean publicOnly, Boolean skipCheckThis, Boolean fillCache, StackCrawlMark& stackMark) +256
   System.Activator.CreateInstance(Type type, Boolean nonPublic) +127
   System.Activator.CreateInstance(Type type) +78
   Ambit.Configuration.Core.ApplicationConfiguration.BuildType(ApplicationConfigurationOptions options, Type t) in d:\Workspaces\Frameworks\Ambit.Configuration.Core\Ambit.Configuration.Core\ApplicationConfiguration.cs:117
   Ambit.Configuration.Core.ApplicationConfiguration.BuildFromAssembly(Assembly assembly, ApplicationConfigurationOptions options) in d:\Workspaces\Frameworks\Ambit.Configuration.Core\Ambit.Configuration.Core\ApplicationConfiguration.cs:61
   Ambit.Configuration.Core.ApplicationConfiguration.BuildCurrentAssembly(ApplicationConfigurationOptions options, Assembly currentAssembly, List`1 exceptions) in d:\Workspaces\Frameworks\Ambit.Configuration.Core\Ambit.Configuration.Core\ApplicationConfiguration.cs:156

[ApplicationConfigurationException: Error processing assembly Ambit.Configuration.Core, Version=0.10.0.0, Culture=neutral, PublicKeyToken=null.]

[AggregateException: One or more errors occurred.]
   Ambit.Configuration.Core.ApplicationConfiguration.Build(ApplicationConfigurationOptions options) in d:\Workspaces\Frameworks\Ambit.Configuration.Core\Ambit.Configuration.Core\ApplicationConfiguration.cs:89
   Ambit.Services.Core.Service.Internal.PlatformServiceConfigurationManager.SetupApplicationConfiguration() in d:\Workspaces\Frameworks\Ambit.Services.Core\Ambit.Services.Core\Service\Internal\PlatformServiceConfigurationManager.cs:97
   System.Lazy`1.CreateValue() +376
   System.Lazy`1.get_Value() +13958447
   Ambit.Services.Core.Service.PlatformServiceHostFactory.CreateServiceHost(Type serviceType, Uri[] baseAddresses) in d:\Workspaces\Frameworks\Ambit.Services.Core\Ambit.Services.Core\Service\PlatformServiceHostFactory.cs:174
   System.ServiceModel.Activation.ServiceHostFactory.CreateServiceHost(String constructorString, Uri[] baseAddresses) +569
   System.ServiceModel.HostingManager.CreateService(String normalizedVirtualPath, EventTraceActivity eventTraceActivity) +1435
   System.ServiceModel.HostingManager.ActivateService(ServiceActivationInfo serviceActivationInfo, EventTraceActivity eventTraceActivity) +76
   System.ServiceModel.HostingManager.EnsureServiceAvailable(String normalizedVirtualPath, EventTraceActivity eventTraceActivity) +901

[ServiceActivationException: The service '/Billing/BillReview/BillReviewService.svc' cannot be activated due to an exception during compilation.  The exception message is: One or more errors occurred..]
   System.Runtime.AsyncResult.End(IAsyncResult result) +624346
   System.ServiceModel.Activation.HostedHttpRequestAsyncResult.End(IAsyncResult result) +235291
   System.Web.AsyncEventExecutionStep.OnAsyncEventCompletion(IAsyncResult ar) +166


Version Information: Microsoft .NET Framework Version:4.0.30319; ASP.NET Version:4.0.30319.34237


Mar 6, 2015 at 12:27 AM
Edited Mar 6, 2015 at 12:28 AM
Hmmm, I'm not sure what's up with your setup, but "V8_Net_Proxy_x64.dll" should not be in the root of the bin folder. It's looking there and can't find it, and it shouldn't. Are you adding that as a reference? You shouldn't add anything as a reference except the engine and the shared types. How is the file and directory structure setup in the bin folder?
Mar 6, 2015 at 12:33 AM
Edited Mar 6, 2015 at 12:34 AM
BTW: The error still means you have DLLs mixed with the wrong architecture. "V8_Net_Proxy_x64.dll" may be trying to load a V8 dll, and you may have the x86 one there, assuming you are trying to flatten the folder structure to one folder.
Mar 6, 2015 at 5:22 PM
The only files I have referenced are V8.Net and V8.Net.SharedTypes.
When I build locally, the other dlls populate in the bin/x64/. For some reason, when it builds on the server, they all go straight to bin. I've tried copying the /x64/ folder structure in to bin on the server, but I still get the same error.

Additionally, I completely deleted the x86 dlls from the solution.
...
OK, so I did finally get it to work on the server. I had to copy the x64 folder from the project folder to the bin, and then delete the two x64 dlls in the bin root folder.
If you have any suggestions as to how to make this happen automatically, that would be great. I'm going to talk with our DevOps engineers today to see why it's acting the way it is.



Mar 7, 2015 at 1:33 AM
FYI: V8.Net does allow flattening all files into a single folder. You just have to make sure to copy only the x64 files. Also, to have a flattened hierarchy, there must not be a bin/v8.net, bin/x86, nor bin/x64 sub-folder, or it will not work. If none of those folders exist, the files should load from one place.