I am trying to add some external DLLs to the Acumatica Customisation project but upon publishing it results in "System.BadImageFormatException: Format of the executable (.exe) or library (.dll) is invalid."
Error Image:
I already have added multiple DLLs to the Customisation. And was using the method specified here: Acumatica unable to publish the Customization Package to skip over the errors, but in this case it does not seem to be working.
The first step should be identifying which DLL is the culprit. I suggest you create an empty project and put the files in there one by one with the ignore rules. Maybe you missed to add ignore rule for one of the files.
This error happens because Acumatica attempts to parse the DLL as a .Net framework assembly. If you add non .Net assembly such as native x86/x64 compiled libraries you need to add the ignore rule so Acumatica doesn't attempt to parse it.
If the error is coming from a DLL you compiled, make sure it was compiled in Any CPU platform. This prevents any incompatibility related to 32 bit/64 bit mismatch.
This is just odd.
I'm getting a build error in ServiceStack.Text after just bringing down the latest build from GitHub.
if (endpointUrl.IsNullOrEmpty() || !endpointUrl.StartsWith("http"))
return null;
Error 1 No overload for method 'IsNullOrEmpty' takes 0 arguments
ServiceStack\src\ServiceStack.Common\Messaging\ClientFactory.cs 10 18
ServiceStack.Common
I'm also getting bunch of other build errors:
Error 35 'int' does not contain a definition for 'Times' and no extension method 'Times' accepting a first argument of type 'int' could be found (are you missing a using directive or an assembly reference?) ServiceStack.Redis\src\ServiceStack.Redis\Messaging\RedisMqServer.cs 192 37 ServiceStack.Redis
and after downloading the ServiceStack branch, I even tried opening ServiceStack-master\src\ServiceStack.sln and tried to build and it's totally broken:
I don't know what's going on here, there can't possibly be this many build errors if any right? I pray not but it seems as such.
Purpose of this post, what I'm asking about and need help clarifying and resolving (mythz???)
I need input from ServiceStack here on the following:
1) are the builds really this broken? Am I imagining this?
2) The branch stucture on GitHub is all over the place meaning I'm finding dup project folders all over and I do not know what this ServiceStack branch is as in it's src folder has a ton of projects there, different versions, as well as doesn't have projects like ServiceStack.Text, etc. so I don't know what's going on here. I want to use the basic core of service stack but there's like repeated stuff everywhere overall on GitHub. I need ServiceStack to clear all this up for me.
Here is my code, so you can see for yourself, it doesn't build.
This one won't build in terms of the ServiceStack projects - it's my solution in which I'm simply trying to include the ServiceStack projects I need along with my own projects that are using ServiceSTack. All I did was downoad those individual projects from https://github.com/ServiceStack then added them to my solution and made sure that any references to each other were now Project references, no longer binary..I removed the binary refs and readded them as project refs. So for example ServiceStack.Common depends on ServiceStack.Text but it was referencing it via binary so I removed it and readded the reference to ServiceStack.Text as a project ref now because in the end we plan on being able to look at and work with the base Stack code. The errors I posted above are happening in this Solution for ServiceStack related projects.
This one won't build - it's a download of the ServiceStack branch master (originally folder name is ServiceStack-master, I removed the -master)
UPDATE: yes I confirmed it's a bad build checked in on the GitHub site (refering to the ServiceStack branch master right above here). I had to remove unused using statements that were causing the build to fail and one of these was a dup using statement causing part of the build failure. I am surprised at this...this stuff should build and people should be checking in code that BUILDS successfully! common! Yes mythz, any dev trying to consume your API would be pissed that there are so many build erros all the time, I can't even get our protype going because this is not the only solution that won't build. First we had the Examples solution all breaking and now the core. I'm willing to fix these if I can but I honestly can't believe it's been a mountain to try to even use this API because of these checked in builds that are failing.
This one Will build because it was Nuget down, so ServiceStack is referencing other layers via binary references in the lib folder so this builds...probably builds here because someone has a working set of builds across all core projects but the stuff on the site for download is not the same revision and broken when you try to use them as project references (source code)?? Just my conclusion as it's only building IF you are using binary references to the lib folder. We want the source, not the binaries to work inside our solution so this is a brick wall for me
There are a lot of big changes happening on master right now - it will be unstable for a while.
I suggest you branch from the v3-fixes tag or pull the references from nuget.
#CoffeeAddict
Yesterday, the mythz answered about these problems in your previous question
"#CoffeeAddict like I said before, ServiceStack's is undergoing significant re-factoring and master in alpha and not for public use. While everything still builds for me and tests still pass in CI, it will be frequently unstable until its in beta. You're likely mixing v3 with v4 dlls which are technically incompatible. The release on NuGet is off the v3 branches of each project, that's what you should checkout if you want to build from src. Any contribs should be done to v3-fixes only - see Contributing docs for more info. – mythz 9 hours ago"
well looks like when I had downloaded all the stack branches, at the time earlier today contributors had checked in broken builds. Fabulous.
I just got latest early this morning, and appears people must have fixed the build and checked some stuff back in for various core projects. Now it builds.
Suggestion to mythz, get CI in place NOW. Don't wait for v4. This cost me a freakin day of trying various things to get this stuff to build and the problems were across several projects. This shouldn't happen, setup CI please. It's 2am and nobody using this project should have to deal with it.
I will contribute but first I had to get a full build to work! Not too happy as no dev would be wasting an entire day getting ServiceStack to build.
To compile v3:
Would someone with true knowledge post PROPER instructions on compiling v4 or v3? I had no luck with the build.bat files for v3 or v4, and opening solutions will not compile for most.
git clone servicestack, servicestack.text, redis, ormlite
make a new directory and copy from under src so you have these:
ServiceStack
ServiceStack.Client
ServiceStack.Common
ServiceStack.Interfaces
ServiceStack.OrmLite
ServiceStack.Redis
ServiceStack.Server
ServiceStack.Text
open csproj for ServiceStack.Interfaces ... right click properties, go to the signing tab, click the combo, new, type in your own signing pfx, I used servicestackInterfaces.pfx (doesn't matter) and make up a password.
Compiles fine, since it has not much referenced.
saved solution as ServiceStackV3 in folder C:\2015\SSv3compile
add csproj ServiceStack.Text, set signature, compiles ok
add csproj ServiceStack.Common, set signature, remove references, add references using solution for interface, text, compiles ok
add csproj ServiceStack.Client, set signature, remove references, add references using solution for interface, text, compiles ok
add csproj ServiceStack, set signature, remove references, add references using solution for client, common, interface, text, compiles ok
add csproj ServiceStack.OrmLite, set signature, remove references, add references using solution for common, interface, text, compiles ok
add csproj ServiceStack.Redis, set signature, remove references, add references using solution for common, interface, text, compiles ok
add csproj ServiceStack.ServiceStack.Server, set signature, remove references, add references using solution for Servicestack, ServiceStack.Client, ServiceStack.Common, ServiceStack.Interface, ServiceStack.Text, ServiceStack.Ormlite, ServiceStack.Redis
compiles ok
have some more trouble compiling the tests...
and finding so many tweaks and changes which are for me maddening to find
(endless agentransack searching for "namespace ISomethinMissing" in *.cs
... there seems to be namespace ServiceStack with cs code contained in projects other than Servicestack...
isn't that VERY improper? (now you require both DLLs? why not one?)
whatever...its free and works for what I wanted.
looks like there is some code leakage from v4...
after getting my head around v3, not sure I want to buy v4 - I will probably buy it in the future, I expect, and hope someday I can just clone and compile from the solution
ANyway, I love servicestack and have been
replacing old webservices
and the config nightmares of WCF with great happiness...
I say it is well worth the initial hassle.
I put this all in code block because I found the editor wouldn't accept this simple text when it was in a numbered list. whatever.
I have Objections-iOS as a 3rd party framework, recognised by XCode, but not by apportable.
In essence, #import <Objection-iOS/Objection.h> does not work so apportable chokes at this point.
I am aware of the header_path(s) property in the configuration, but try as I might, I still could not get apportable to load the headers from $project_root/Frameworks/Objection-iOS.framework
Have any of you had a similar problem?
You would need to build that framework as a sub-project to get it to work the headers from the framework need to be re-organized to be in a directory called Objection-iOS to reference the correct paths. Unfortunately the linker does not support framework inclusions yet so we cannot build real frameworks as of current to add the -framework parameter to the compilation steps. On iOS and MacOSX this basically adds the Objection-iOS.framework/Headers into the include paths but remaps that part to be named Objection-iOS.
tl;dr;
Create a directory called Objection-iOS, add a header_paths entry that points to the container of that directory and it should pick up on the headers
I'm developing ASP.NET MVC with extensive usage of Spring.net.
I have lots of services implemented in different assemblies. The purpose of using Spring and abstract interfaces is to decouple the application from the implementation of services. For example, the Data Access Layer is currently implemented by NHibernate, but the solution is designed to allow this to change.
So I have defined lots of Spring objects from foreign assemblies e.g.
<object id="RepositoryFactory" type="Org.Zighinetto.MyApp.NHibernateBasedRepositoryFactory, Org.Zighinetto.MyApp,NHibernate" />
As we all know, this works as soon as Org.Zighinetto.MyApp.NHibernate.dll example assembly either
Is in GAC
Is in bin directory
As of today, in order to allow quick debugging by hitting F5, I have set a dependency from the main project to all projects it depends on. As we all know, Spring is designed to allow us to cut the dependency between projects, but in this case I use dependencies only to tell Visual Studio to compile and deploy the DLL automatically, otherwise I would have to copy the right DLLs every time I want to debug my project.
The question is straightforward: given that I want to compile, at least in Release mode, my DLLs without unneeded dependencies, how can I make sure that Visual Studio, when I hit F5, automatically compile and deploys all of the Spring-required DLLs (which can be hardcoded by me somewhere, e.g. in a post-compile script) into bin directory?
In the Org.Zighinetto.MyApp example above, I want that once Org.Zighinetto.MyApp.dll gets compiled, VS compiles and deploy also Org.Zighinetto.MyApp.NHibernate.dll without having an explicit reference from .MyApp to .NHibernate
The dependency in you project file does not make the resulting assembly in any way dependent on these referenced files. You can safely have the dependencies there during development and compile your project.
The resulting output will still work when you swap out the assemblies that contain the implementation.
I use third party static library (provided as a .LIB file without source code) in my project. For linking purposes it is enough to add it via "Properties/Linker/Input->Additional Dependencies"
This library is not used in any other project in the solution.
I wonder if I should add it as an item to project file itself. The advantages that I see: it will be immediately obvious that this project uses it and one wouldn't have to add it to version control system manually (anything that is a part of the project/solution is added automatically if you use something like AnkSVN).
The project in VCS must be buildable. It is impossible without the lib. So you should add it.