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.
I have a Liferay 6.1 instance with a custom classic theme, but trying to upgrade it to 7.0 is being so painful that I decided to take Liferay 7's classic theme (downloaded from here).
To bring it into Eclipse - Liferay IDE I created a new module (theme) project and imported files, but trying to deploy it was sending errors (for example, no init.ftl, stuff like that, unexpected given I am using the repo source).
When I arrived to this error, solved it and tried to deploy, it again said there's no init.ftl... Then I searched for it into the war and it actually wasn't there! No idea about what but... I noticed a portal_pop_up.ftl that doesn't exist in my source code!!! What is going on? I'm pretty confused.
Thanks!
Ok, the problem was with code downloaded from Github.
If you want to use classic-theme, just create an "empty" theme in the IDE and then overwrite it's files with the ones from auto"deployed" classic-theme in the L7 instance, in /opt/liferay/osgi/wabs.
Recently I am working on servicestack project. When I am trying to add open ServiceStack.ServiceInterface in project it is showing below error.
PFB image for code.
As suggested in error, when i am trying add open ServiceStack.Interfaces then it is showing dll is not present.
please tell me why it is showing error?
What is different of this two DLL?
ServiceStack.ServiceInterfaces contains interfaces used by the ServiceStack webstack while ServiceStack.Interfaces is used by the various other ServiceStack projects (like OrmLite) as well.
ServiceStack.ServiceInterfaces depends on ServiceStack.Interfaces, which means you have to install it as well (it is a seperate nuget package)
I've made a hello world module for orchard following this tutorial http://docs.orchardproject.net/Documentation/Building-a-hello-world-module
I've opened up the csproj in VS2012 and changed the projecttype guids to be MVC https://stackoverflow.com/a/12811015/828859
When I build the module in MVC orchard uses the published DLL.
When i attempt to go to the /helloworld route i get 404 resource cannot be found
When i save a file and let the dynamic compilation in orchard do it's thing it works fine.
I would like to be able to deploy with a DLL so does anyone have any ideas on the problem?
Ok, two things.
First - you won't be able to deploy your module as a single DLL. There are lots of things that do not get compiled into the DLL, eg. the Module.txt manifest. It has to be there under /Modules/<YourModuleName> (as well as module's .csproj file, .cshtml files and some more). Otherwise, Orchard won't be able to find your module.
So the source code for the module has to be there, although if you build it and the module's DLL is in /Modules/<YourModuleName>/bin folder, dynamic compilation won't kick in.
Second - module development should be done using full source code - not with the downloaded deployment package. Please read here how to get full source code.
I'd like to ask you for best practices with developing with Liferay SDK.
I have the SDK downloaded, I have Eclipse ready, it works, I can create new portlets and run local Liferay instance to test it.
Here is my situation - all the source code I have is in the Eclipse workspace, currently it is only portlets what I'm working on.
Liferay SDK I have in completely different location than workspace. Let's say ~/dev/liferay_sdk.
Eclipse workspace is located in ~/workspace.
At the beggining, it was not working like that. Eclipse from some reason can't find or use Liferay SDK. When I changed "Project validation" in Eclipse/Liferay configuration to "Ignore" the "Liferay Plugin SDK is not valid", it started to work without problems.
Next problem happend when it comes to need to build a WAR for example.
In the portlet directory in the workspace is present "build.xml" file. But inside it refers to another xml file, which should be located one directory up, and this one refers to more thing in relatively location and so on.
In short, it assumes that you have the portlets etc, inside the Liferay SDK.
Like "~/dev/liferay_sdk/portlets".
My question is, Am I wrong completely, or could you suggest me the best practices with this?
I don't want to mix SDK and the code, it sounds wrong to me.
Thanks for help!
I think, the best practice is still when your portlet projects are located inside the Liferay Plugins SDK directory. That way you can take all the advantages of the Liferay IDE plugin for Eclipse, for example. Because as far as I understand Liferay IDE will not allowed you to have portlet projects in another location. It's pretty easy to import projects to Eclipse from inside the Liferay SDK directory, and that's not problem.
But I also faced the same sort of problem when tried to save portlet project to the Git repository. Possible solutions with symbolic links didn't work correctly on every system. Thus I slightly modified the build.xml file to be able to run ant tasks from any directory. For portlets it was something like that:
<project name="your-portlet" basedir="." default="deploy">
<property file="build.properties" />
<property name="project.dir" value="${liferay.sdk.home}" />
<import file="${project.dir}/build-common-plugin.xml" />
</project>
Notice that you should define property "liferay.sdk.home" in build.properties and it should be path to the Liferay Plugins SDK.
As for other types of Liferay plugins (themes, hooks, etc.) you should import another build file for building that type of plugin. For example, for themes it will be:
<import file="${project.dir}/themes/build-common-theme.xml" />
Hope you'll get the idea. :) But think twice before doing something like that.
Liferay plugins are developed inside the Liferay Plugins SDK, its called SDK for a very good reason.
I don't find anything wrong with the plugins-SDK and the code tied togather, below are few reasons why:
If you see the liferay repository of plugins on github, you would find all the sample portlets and other plugins are stored in their respective folders inside plugins-SDK.
So if you want to develop liferay plugins (with or without IDE), the best practice (the only efficient way I think) is to have the projects created inside the respective folders of plugins SDK like portlet projects inside portlets folder, hook project inside hooks folder etc.
If you have used Liferay IDE when you create a plugin project (Liferay project) in this IDE you specify the SDK and the server runtime and what it does is it creates the project inside your Plugins SDK and copies the .settings, .classpath & .project file inside the project created. It does not create the project inside your workspace as eclipse normally does for other projects.
Hope I have managed explain it clearly and this was what you wanted.
I'm already quite happy with the other answers, this could have been distributed through comments at those, but a separate answer gives some more structuring options:
As Prakash says, it's not really bad to do that. In addition to his answer, you do not need to have your code in the workspace directory. Eclipse is happy to put it anywhere in the filesystem - thus while you work with Eclipse you don't even care where exactly your code is (and as you check it into version control - right? - you actually never need to care.
If you want to use Liferay's OOTB ant scripts: They are geared towards exactly the setup you describe: Work in the SDK directory. It's actually not bad, but if you don't like it, you just have to accept that you can't work with build.xml without changing it (like Artem suggests).
Another option is to use maven - this also bypasses the sdk (and the Liferay IDE integration), so you're again free to put your sourcecode whereever you like and let maven do the rest.
I can imagine some rather esoteric and rare issues with Artem's suggestion (like referring to custom parent themes when you imply some relative position) but I consider that as extremely minor, so if that works for you: Go ahead. Just keep in mind that you don't fulfill the basic assumptions that the SDK makes, so you might have to change things that violate the assumptions. I can't imagine this being too hard if you keep this in mind.
Of course, what you miss with that solution is the neat handling of including build.${username}.properties - you'll have to have your own build.properties that define ${liferay.sdk.home}. If you're not working in a team, that's ok. Otherwise you'll have to invent this yourself (and code it) or rely on global parameters to be configured with every team member.