Jump to content


Building P4API.NET for x86/x64


  • Please log in to reply
8 replies to this topic

#1 mlussier

mlussier

    Member

  • Members
  • PipPip
  • 19 posts

Posted 11 August 2014 - 06:55 PM

I am trying to add the P4API.NET .dlls to one of my projects.  However, if I use the .dlls that are provided on the Perforce APIs downloads page, I get the following warning:

Quote

There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "p4api.net, Version=2014.1.85.4506, Culture=neutral, PublicKeyToken=f6b9b9d036c873e1, processorArchitecture=AMD64", "AMD64".

I tried ignoring the warning, but when I try to run, it crashes when trying to load the p4api.net assembly (incorrect format error).

So I am now trying to build the .dll from the source.  However, I'm running into issues trying to follow the directions in the release notes.  After downloading p4api_vs2010_static.zip, I stumble on step 3, which is to load the solution in Visual Studio 2010.  I don't see a solution file in the provided zip, nor do I see a way to generate a solution file.

I also tried using jam, but ran into this error:

Quote

Error E2075: Incorrect command line option: /Foobjects\p4api.obj

I don't see Foobjects anywhere in the Jam files, so I'm not sure where it is coming from.  At this point, I feel like I'm missing something obvious.  Any ideas on what I am missing?

#2 p4bill

p4bill

    Advanced Member

  • Members
  • PipPipPip
  • 217 posts

Posted 11 August 2014 - 07:26 PM

Are you trying to build a x86 or x64 project? That is what the warning likely indicates, a mismatch between p4api.net and your project.

For x86, get p4api.net.zip from here:

ftp://ftp.perforce.com/perforce/r14.1/bin.ntx86/

For x64, get p4api.net.zip from here:

ftp://ftp.perforce.com/perforce/r14.1/bin.ntx64/

The step 3 that you mention refers to the p4api.net solution which can be found with the source (p4api.net-src.zip), only available in the x86 ftp line:

ftp://ftp.perforce.com/perforce/r14.1/bin.ntx86/

those first 3 steps show how the C++ API is included in the correct P4API.NET directories in order to build the P4API.NET solution from source.

#3 mlussier

mlussier

    Member

  • Members
  • PipPip
  • 19 posts

Posted 11 August 2014 - 07:45 PM

Ah, I was looking under the x64 ftp, which is why I didn't see the solution source.  I've managed to get the source and successfully build it with a x64 configuration, but I still get the AMD warning from the .dlls that I build.  Any idea where in the project properties that is coming from?

#4 mlussier

mlussier

    Member

  • Members
  • PipPip
  • 19 posts

Posted 11 August 2014 - 07:58 PM

Nevermind, I didn't have the .net project set correctly.  Thanks for your help in locating the source solution.  It might be a good idea to have it in the x64 ftp in the future (unless there is a reason why it isnt).

#5 p4bill

p4bill

    Advanced Member

  • Members
  • PipPipPip
  • 217 posts

Posted 11 August 2014 - 08:51 PM

Good suggestion, I don't know that there is a reason it is not. I'll bring that up here.

#6 mlussier

mlussier

    Member

  • Members
  • PipPip
  • 19 posts

Posted 12 August 2014 - 04:10 PM

So still running into runtime issues.  I've tried building the source in both x86/Win32 and x64 modes, but no combination seems to work.

The problem seems to lie with p4bridge.dll, as p4api.net.dll seems to load fine.  My program will run until I call Repository.Connection.Connect().  It will then crash in Connection.cs line 251 (which is when I am assuming it tries to load p4bridge.dll).

The project I am trying to add these .dlls to is a C# ASP.NET Web API 2.0 project, using .NET Framework 4.5, which outputs a single .dll to be hosted using IIS.  Like I mentioned earlier, no combination of building the perforce dlls and my dlls in any configuration mode seems to work.  Any ideas on what is going wrong?

#7 p4bill

p4bill

    Advanced Member

  • Members
  • PipPipPip
  • 217 posts

Posted 12 August 2014 - 05:15 PM

Have you tried putting the p4bridge.dll in the same location as the single .dll that is hosted using IIS?

The only other thing that comes to mind regarding problems with projects using IIS is access level or application permissions. I recall some others running into issues when they did not have the necessary access set for the application.

If you are building p4api.net from source, can you build in debug mode and step though up to the crash? Line 251 in Connection.cs (that I am looking at) is:

if ((_p4server != null) && (_p4server.pServer != IntPtr.Zero))

That is all I have off the top of my head. We may want to open a support ticket if you cannot get this running soon.

#8 mlussier

mlussier

    Member

  • Members
  • PipPip
  • 19 posts

Posted 12 August 2014 - 06:40 PM

Ah, it looks like p4bridge.dll is not being deployed with the rest of the .dlls, because it is not explicitly added as a reference in the project.  Good catch.

#9 alanschu

alanschu

    Newbie

  • Members
  • Pip
  • 1 posts

Posted 30 September 2015 - 11:01 PM

Sorry for the thread bump but this is close to what I am working on at the moment and it might be useful for others within the context of this discussion.

I recently was able to create a solution for this but it turns out that we really prefer Any CPU configurations.  I did get burned with the BadImageFormatException when it was deployed to one of the build machines.  Is there a way to make the include work with some platform specific paths. I put p4api.net.dll into respective AMD64 and x86 directories with updated app.config references, and that seems to work fine. But p4bridge.dll is very particular: if I don't have it added to the project root and Copy Always the application doesn't find p4bridge.dll

I tried manually copying the platform specific dll to the output directory root as a post build event but that doesn't work.  (Which is super odd since if I have a version at the project root with Copy Always set, it just overwrites itself and it has no issues with that).
I also tried setting up a probling PrivatePath to point to the platform specific .dll but that didn't work either.

I am using r14.3 from the FTP.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users