I have application developed using Grails 2.5.
In the the "Config.groovy" file i have included external configuration file like this:
grails.config.locations = []
def locationAdder = ConfigFinder.&addLocation.curry(grails.config.locations)
[CONFIG-1 : "base_config.groovy",
CONFIG-2 : "app_configuration.groovy"
].each { envName, defaultFileName -> locationAdder(envName, defaultFileName) }
In the "app_configuration.groovy" file i have all the application level configuration.
My question is how to catch the "syntax errors" when server is loading this configuration files, like ex.:
if i have configuration like
some_configuration=["key": "value"]
and if it has an syntax errors like
some_configuration=["key": "value
Notice that above it missed double quote and ending bracket, in this case the server will not load all the configurations.
If any one know that how to catch exception and reload the configurations with corrected configuration.
You can not catch Exception in external config. You may just add some log which in case of failure, at least have got some clue where it is failed.
println "External config: Part 1 loaded "
println "External Config: Part n loaded "
....
Am trying to call a service running in tomcat through remote objects from flex, when i call the remote object it throws flex invalid session error
Channel.Ping.Failed error There was an unhandled failure on the server. The FlexSession is invalid. url: 'http://localhost:8080/Server/messagebroker/amf/'
[RemoteObject destination="reinforcementService" channelSet="[ChannelSet null ]"]
Send failed
Code
<s:CallResponder id="getReinforcementsResult"/>
<services:ReinforcementService id="reinforcementService" fault="Alert.show(event.fault.faultString + '\n' + event.fault.faultDetail)" showBusyCursor="true"/>
<s:RemoteObject id="ro2" destination="reinforcementService" endpoint="{parentApplication.serviceURL}" result="ro2_resultHandler(event)" fault="ro2_faultHandler(event)"/>
and i call the method using
ro2.getReinforcements();
and i disconnect the remote object in result handler to avoid DuplicateFlexSessions error
ro2.disconnect();
and the channel definition in services-config.xml is as follows
<channel-definition id="my-amf" class="mx.messaging.channels.AMFChannel">
<endpoint url="http://{server.name}:{server.port}/{context.root}/messagebroker/amf" class="flex.messaging.endpoints.AMFEndpoint"/>
<properties>
<polling-enabled>true</polling-enabled>
<add-no-cache-headers>true</add-no-cache-headers>
<!-- <invalidate-session-on-disconnect>true</invalidate-session-on-disconnect> -->
<invalidate-session-on-disconnect>true</invalidate-session-on-disconnect>
</properties>
</channel-definition>
how to solve this problem?
When my Grails application crashes, it shows the error and the stacktrace on the error page because the error.gsp page has the following snippet <g:renderException exception="${exception}" />. However nothing gets logged in the log file.
How can I change this? because for the production application I plan to remove the renderException because I don't want users to see the entire stacktrace.
My log4j settings are as follows:
appenders {
rollingFile name:'catalinaOut', maxFileSize:1024, fileName:"${System.properties.getProperty('catalina.home')}/logs/mylog.log"
}
root {
error 'catalinaOut'
debug 'catalinaOut'
additivity = true
}
error 'org.codehaus.groovy.grails.web.servlet', // controllers
'org.codehaus.groovy.grails.web.pages', // GSP
'org.codehaus.groovy.grails.web.sitemesh', // layouts
'org.codehaus.groovy.grails.web.mapping.filter', // URL mapping
'org.codehaus.groovy.grails.web.mapping', // URL mapping
'org.codehaus.groovy.grails.commons', // core / classloading
'org.codehaus.groovy.grails.plugins', // plugins
'org.codehaus.groovy.grails.orm.hibernate', // hibernate integration
'org.springframework',
'org.hibernate',
'net.sf.ehcache.hibernate',
'grails.app'
debug 'grails.app'
}
I'm running the app in development as grails run-app
I use these settings for console and file based logging. You can remove stdout if you don't want/need console. Just copy all your error classes in the corresponding list.
log4j = {
def loggerPattern = '%d %-5p >> %m%n'
def errorClasses = [] // add more classes if needed
def infoClasses = ['grails.app.controllers.myController'] // add more classes if needed
def debugClasses = [] // add more classes if needed
appenders {
console name:'stdout', layout:pattern(conversionPattern: loggerPattern)
rollingFile name: "file", maxFileSize: 1024, file: "./tmp/logs/logger.log", layout:pattern(conversionPattern: loggerPattern)
}
error stdout: errorClasses, file: errorClasses
info stdout: infoClasses, file: infoClasses
debug stdout: debugClasses, file: debugClasses
}
I'm using AS3WebSocket module to connect web sockets. It works well when I launch flash locally (flash file is marked as trusted in global settings).
But when I open server page with flash, it doesn't work. I've no error messages, just "disconnect" in log.
WinServer2012, IIS, ASP.NET MVC4
Here are logs:
ws init begin: ws://www.sample.biz/WsHandler.ashx?userId=5
Disconnected null[object WebSocket]
And code:
function SYS_wsInit_begin():void
{
writeLog("ws init begin: " + ws_init_url);
trace(ws_init_url);
try
{
websocket = new WebSocket(ws_init_url,"*");
websocket.addEventListener(WebSocketEvent.CLOSED, handleWebSocketClosed);
websocket.addEventListener(WebSocketEvent.OPEN, handleWebSocketOpen);
websocket.addEventListener(WebSocketEvent.MESSAGE, handleWebSocketMessage);
websocket.addEventListener(WebSocketErrorEvent.CONNECTION_FAIL, handleConnectionFail);
websocket.connect();
}
catch (err:Error)
{
writeLog("ws init failed: " + err.message + err.name);
}
}
function handleWebSocketClosed(event:WebSocketEvent):void
{
writeLog("Disconnected " + event.message + event.target);
trace("Disconnected");
}
function handleWebSocketOpen(event:WebSocketEvent):void
{
writeLog("Connected");
trace("Connected");
}
function handleConnectionFail(event:WebSocketErrorEvent):void
{
writeLog("Connection Failure: " + event.text);
trace("Connection Failure: " + event.text);
}
crossdomain.xml:
<?xml version="1.0" encoding="utf-8" ?>
<cross-domain-policy>
<site-control permitted-cross-domain-policies="all"/>
<allow-access-from domain="*"/>
<allow-http-request-headers-from domain="*" headers="*"/>
</cross-domain-policy>
I've also installed Socket Policy File Server with file:
<?xml version="1.0"?>
<cross-domain-policy xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:noNamespaceSchemaLocation="http://www.adobe.com/xml/schemas/PolicyFileSocket.xsd">
<site-control permitted-cross-domain-policies="*" />
<allow-access-from domain="*" to-ports="*" />
</cross-domain-policy>
What can I do?
Oh, I've resolved the problem.
After reading, http://forums.adobe.com/message/5297747 I've tried to check 843 port with fiddler, but I got only a redirection to index page.
I checked my IIS configuration. There was a binding on 843 port. After the binding was deleted and socket policy file server restarted the Web-socket connection was established!
How do i deploy Microsoft SQL Server Compact 4.0?
SQL Server Compact Edition (currently at version 4.0) is:
a free, embedded database that software developers can use for building Windows desktop applications. It has a small footprint and supports private deployment of its binaries within the application folder.
But how do you actually deploy it?
Microsoft says it can be deployed within the application folder (good) and supports xcopy deployment.
Microsoft also says it cannot be deployed within the application folder (bad), and does not support xcopy deployment.
some people have examples of it using simple xcopy deployment, but they don't go into the details required to complete the deployment
The problem is that you cannot use the ADO OLEdb provider unless it is registered. Registering an OLEdb provider has to be done as an administrator. That means that SQL Server Compact edition will fail with users who are not an administrator.
SQL Server Compact 4.0 comes with a redist_enu.txt file:
The listed .exe files each install its enclosed components to a specific location on the destination computer. This helps to ensure serviceability and technical support. The .dll files enclosed in these .exe files are also available separately in this redist.txt. However, distributions of these separate .dlls may result in issues of serviceability. For more details, please see http://go.microsoft.com/fwlink/?LinkId=94589
Private deployment detection via BreadCrumb: Private deployment of just the native stack and explicit loading of SQL Server Compact Assembly via Assembly.LoadFrom(), .local file, or the use of DLL/COM redirection strategies are not supported and may result in serviceability issues. For more information see http://support.microsoft.com/kb/835322 and http://msdn2.microsoft.com/en-us/library/aa375142.aspx
Microsoft SQL Server Compact 4.0
SSCERuntime_x86-ENU.exe
SSCERuntime_x86-DEU.exe
SSCERuntime_x86-FRA.exe
SSCERuntime_x86-JPN.exe
SSCERuntime_x86-RUS.exe
SSCERuntime_x86-ESN.exe
SSCERuntime_x86-ITA.exe
SSCERuntime_x86-KOR.exe
SSCERuntime_x86-CHT.exe
SSCERuntime_x86-CHS.exe
SSCERuntime_x64-ENU.exe
SSCERuntime_x64-DEU.exe
SSCERuntime_x64-FRA.exe
SSCERuntime_x64-JPN.exe
SSCERuntime_x64-RUS.exe
SSCERuntime_x64-ESN.exe
SSCERuntime_x64-ITA.exe
SSCERuntime_x64-KOR.exe
SSCERuntime_x64-CHT.exe
SSCERuntime_x64-CHS.exe
sqlcese40.dll
sqlceqp40.dll
sqlceoledb40.dll
sqlceca40.dll
sqlceme40.dll
sqlcecompact40.dll
sqlceer40en.dll
sqlceer40cn.dll/sqlceer40zh-CHS.dll
sqlceer40de.dll
sqlceer40es.dll
sqlceer40fr.dll
sqlceer40it.dll
sqlceer40ja.dll
sqlceer40ko.dll
sqlceer40tw.dll/sqlceer40zh-CHT.dll
sqlceer40ru.dll
System.Data.SqlServerCe.dll
System.Data.SqlServerCe.Entity.dll
but it doesn't give any information about how to redistribute SQL Server Compact 4.0.
Randomly spellunking around the undocumented Program Files folder i found 7 dlls:
C:\Program Files\Microsoft SQL Server Compact Edition\v4.0\
sqlceoledb40.dll
sqlceqp40.dll
sqlcese40.dll
sqlceca40.dll
sqlcecompact40.dll
sqlceer40EN.dll
sqlceme40.dll
Note: There are also some child folders with more dlls
i tried copying these 7 dll's to a folder, and tried to open an ADO Connection using the connection string:
Provider=Microsoft.SQLSERVER.CE.OLEDB.4.0;Data Source="store.sdf"
but it fails with 0x80004005 Unspecified error
i tried frobbing the widget, but it grobbed the frobber.
i've created the solution.
SQL Server Compact Edition is comprised of 7 dlls:
sqlceme40.dll The undocumented, native, flat API library (The .net System.Data.SqlServerCe.dll assembly is a wrapper around this dll)
sqlceca40.dll A COM dll that implements Engine, Replication, Error and a few other COM objects
sqlceoledb40.dll A COM dll that implements an OLEdb provider for SSCE (allowing the use of ADO)
sqlcese40.dll unknown
sqlceqp40.dll unknown
sqlcecompact40.dll unknown
sqlceer40en.dll unknown
The problem with trying to simply ship these dlls is that two of them are COM objects. COM object dll's need to be registered, e.g.:
>regsvr32 sqlceca40.dll
>regsvr32 sqlceoledb40.dll
The problem is that registering a COM object requires administrative privileges (using a global solution to solve a local problem). This means that your users would
have to install your application (which you don't want to do)
requires your users to have administrative permissions (which you don't want to do)
Fortunately, starting in 2001 with Windows XP, Microsoft solved this COMmon problem: Registration-Free COM.
First, you will declare that your application has a "dependancy" on SQL Server Compact Edition 4.0. You do this by authoring an assembly manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
version="1.0.0.0"
processorArchitecture="X86"
name="client"
type="win32"
/>
<description>Hyperion Pro</description>
<!-- We have a dependancy on SQL Server CE 4.0 -->
<dependency>
<dependentAssembly>
<assemblyIdentity
type="win32"
name="Microsoft.SQLSERVER.CE.4.0"
version="4.0.0.0" processorArchitecture="x86"
/>
</dependentAssembly>
</dependency>
<!-- We are high-dpi aware on Windows Vista -->
<asmv3:application xmlns:asmv3="urn:schemas-microsoft-com:asm.v3">
<asmv3:windowsSettings
xmlns="http://schemas.microsoft.com/SMI/2005/WindowsSettings">
<dpiAware>true</dpiAware>
</asmv3:windowsSettings>
</asmv3:application>
<!-- We were designed and tested on Windows 7 -->
<compatibility xmlns="urn:schemas-microsoft-com:compatibility.v1">
<application>
<!--The ID below indicates application support for Windows 7 -->
<supportedOS Id="{35138b9a-5d96-4fbd-8e2d-a2440225f93a}"/>
<!--The ID below indicates application support for Windows Vista -->
<!--supportedOS Id="{e2011457-1546-43c5-a5fe-008deee3d3f0}"/-->
</application>
</compatibility>
<!-- Disable file and registry virtualization -->
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v2">
<security>
<requestedPrivileges>
<requestedExecutionLevel level="asInvoker" uiAccess="false"/>
</requestedPrivileges>
</security>
</trustInfo>
</assembly>
You can place this file beside your executable (as Hyperion.exe.manifest), or you can build it into your application as an RT_MANIFEST resource.
Notice that we have a dependancy against as assembly called Microsoft.SQLSERVER.CE.4.0. We create this assembly first by creating a directory called:
Microsoft.SQLSERVER.CE.4.0
When you deploy your application, you will place all 7 dll's that comprise this "assembly" into this Microsoft.SQLSERVER.CE.4.0 subfolder, along with a special .manifest file:
📁C:\
╰──📁Users
╰──📁Ian
╰──📁AppData
╰──📁Local
╰──📁Hyperion Pro
├──📄Hyperion.exe
├──📄Hyperion.exe.manifest
╰──📁Microsoft.SQLSERVER.CE.4.0
├──📄sqlceme40.dll
├──📄sqlceca40.dll
├──📄sqlceoledb40.dll
├──📄sqlcese40.dll
├──📄sqlceqp40.dll
├──📄sqlcecompact40.dll
├──📄sqlceer40en.dll
╰──📄Microsoft.SQLSERVER.CE.4.0.manifest
In other words, the application folder contains your application, and the Microsoft.SQLSERVER.CE.4.0 folder:
Directory of C:\Users\Ian\AppData\Local\Hyperion Pro
05/29/2012 09:23 AM 1,899,008 Hyperion.exe
05/28/2012 01:46 PM 1,587 Hyperion.exe.manifest
05/29/2012 09:27 AM <DIR> Microsoft.SQLSERVER.CE.4.0
2 File(s) 1,900,675 bytes
1 Dir(s) 20,851,503,104 bytes free
The next part of your task is to define the Microsoft.SQLSERVER.CE.4.0.manifest file. Registration-free COM allows a manifest file to declare all the COM objects and their clsid's. This took a lot of reverse engineering. But the assembly manifest for SQL Server Compact Edition 4.0 is:
Microsoft.SQLSERVER.CE.4.0.manifest:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
type="win32"
name="Microsoft.SQLSERVER.CE.4.0"
processorArchitecture="x86"
version="4.0.0.0" />
<!-- OLEDB Provider -->
<file name = "sqlceoledb40.dll">
<comClass
description = "Microsoft SQL Server Compact OLE DB Provider for Windows"
clsid="{2006C53A-C915-41EA-BAA9-9EAB3A1FBF97}"
threadingModel = "Both"
progid = "Microsoft.SQLSERVER.CE.OLEDB.4.0" />
</file>
<!-- Native flat engine library -->
<file name="sqlceme40.dll" />
<!-- Engine and Replication COM object -->
<file name="sqlceca40.dll">
<comClass description="Active SSCE Engine Object"
clsid="{68D45319-3702-4837-9F8E-DA6845D82482}"
threadingModel="Both"
progid="SSCE.Engine.4.0" />
<comClass description="SSCE Error Object"
clsid="{36228F21-B5C7-4054-8DC2-47D3E236E8B5}"
threadingModel="Both"
progid="SSCE.Error.4.0" />
<comClass description="SSCE Param Object"
clsid="{0B3A7B75-A9B0-4580-9AA5-1A7DA47AD1CB}"
threadingModel="Both"
progid="SSCE.Param.4.0" />
<comClass description="Active SSCE Replication Object"
clsid="{11D5B2D4-26A4-44F5-A48B-0FAC3A919ED8}"
threadingModel="Both"
progid="SSCE.Replication.4.0" />
<comClass description="Active SSCE remote data access Object"
clsid="{58BC9AD6-BF11-40B3-9AB1-E3F2ED784C08}"
threadingModel="Both"
progid="SSCE.RemoteDataAccess.4.0" />
<typelib tlbid="{CE4AACFA-3CFD-4028-B2D9-F272314F07C8}"
version="4.0"
helpdir=""/>
</file>
<comInterfaceExternalProxyStub
name="ISSCEEngine"
iid="{10EC3E45-0870-4D7B-9A2D-F4F81B6B7FA2}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{CE4AACFA-3CFD-4028-B2D9-F272314F07C8}" />
<comInterfaceExternalProxyStub
name="ISSCEError"
iid="{31155A3B-871D-407F-9F73-DEBFAC7EFBE3}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{CE4AACFA-3CFD-4028-B2D9-F272314F07C8}" />
<comInterfaceExternalProxyStub
name="ISSCERDA"
iid="{4F04F79D-1FF1-4DCD-802B-3D51B9356C14}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{CE4AACFA-3CFD-4028-B2D9-F272314F07C8}" />
<comInterfaceExternalProxyStub
name="ISSCEParams"
iid="{A78AFF90-049C-41EC-B1D8-665968AAC4A6}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{CE4AACFA-3CFD-4028-B2D9-F272314F07C8}" />
<comInterfaceExternalProxyStub
name="ISSCEParam"
iid="{A9876C60-2667-44E5-89DB-E9A46ED392C0}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{CE4AACFA-3CFD-4028-B2D9-F272314F07C8}" />
<comInterfaceExternalProxyStub
name="ISSCEErrors"
iid="{C40143CA-E9F9-4FF4-B8B4-CC02C064FC1B}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{CE4AACFA-3CFD-4028-B2D9-F272314F07C8}" />
<comInterfaceExternalProxyStub
name="ISSCEMerge"
iid="{C6EB397F-D585-428D-A4F4-454A1842CB47}"
proxyStubClsid32="{00020424-0000-0000-C000-000000000046}"
baseInterface="{00000000-0000-0000-C000-000000000046}"
tlbid = "{CE4AACFA-3CFD-4028-B2D9-F272314F07C8}" />
<file name="sqlceqp40.dll" />
<file name="sqlcese40.dll" />
<file name="sqlcecompact40.dll" />
<file name="sqlceer40EN.dll" />
</assembly>
The a final gotcha is that, in the same way we have a dependancy on an assembly called Microsoft.SQLSERVER.CE.4.0, SQL Server Compact Edition 4.0 in turn has a dependancy on an assembly called Microsoft.VC90.CRT. Fortunately your install of SQLCE ships with a copy of this assembly:
📁Microsoft.VC90.CRT
├──📄Microsoft.VC90.CRT.manifest
╰──📄msvcr90.dll
This means the final directory structure is:
📁C:\
╰──📁Users
╰──📁Ian
╰──📁AppData
╰──📁Local
╰──📁Hyperion Pro
├──📄Hyperion.exe
├──📄Hyperion.exe.manifest
╰──📁Microsoft.SQLSERVER.CE.4.0
├──📄Microsoft.SQLSERVER.CE.4.0.manifest
├──📄sqlceme40.dll
├──📄sqlceca40.dll
├──📄sqlceoledb40.dll
├──📄sqlcese40.dll
├──📄sqlceqp40.dll
├──📄sqlcecompact40.dll
├──📄sqlceer40en.dll
╰──📁Microsoft.VC90.CRT
├──📄Microsoft.VC90.CRT.manifest
╰──📄msvcr90.dll
For Sql Server Ce 4.0 SP1:
Instead of tackling all the gritty stuff of deployment, I just opted to include the setup files themselves into my exe as EmbeddedResource and did this little helper:
public static class RedistHelper
{
private static readonly ILog Log = LogManager.GetLogger(
MethodBase.GetCurrentMethod().DeclaringType);
private static readonly string SqlCeRedistName64 = "SSCERuntime_x64-ENU.exe";
private static readonly string SqlCeRedistName32 = "SSCERuntime_x86-ENU.exe";
private static readonly Dictionary<string, Assembly> Assemblies =
new Dictionary<string, Assembly>(StringComparer.OrdinalIgnoreCase);
private static string SqlCeRedistName
{
get
{
return Environment.Is64BitOperatingSystem
? SqlCeRedistName64
: SqlCeRedistName32;
}
}
public static bool IsSqlCeInstalled()
{
RegistryKey localKey = RegistryKey.OpenBaseKey(RegistryHive.LocalMachine,
RegistryView.Registry64);
RegistryKey ret = localKey.OpenSubKey(
#"SOFTWARE\Microsoft\Microsoft SQL Server Compact Edition\v4.0\ENU");
return ret != null;
}
private static byte[] ReadFully(Stream input)
{
byte[] buffer = new byte[16 * 1024];
using (MemoryStream ms = new MemoryStream())
{
int read;
while ((read = input.Read(buffer, 0, buffer.Length)) > 0)
ms.Write(buffer, 0, read);
return ms.ToArray();
}
}
public static Assembly OnCurrentDomainOnAssemblyResolve(object sender,
ResolveEventArgs args)
{
Assembly dll;
var name = new AssemblyName(args.Name).Name + ".dll";
if (!Assemblies.TryGetValue(name, out dll))
{
Assembly res = typeof(RedistHelper).Assembly;
using (Stream input =
res.GetManifestResourceStream(typeof(RedistHelper), name))
{
if (input == null)
{
Log.WarnFormat("Assembly {0} does not contain {1}", res, name);
return null;
}
dll = Assembly.Load(ReadFully(input));
if (dll == null)
{
Log.WarnFormat("Assembly {0} failed to load.", name);
return null;
}
Log.InfoFormat("Loaded assembly {0}.", name);
Assemblies[name] = dll;
return dll;
}
}
return dll;
}
public static void InstallSqlCe()
{
using (Stream stream =
typeof(RedistHelper).Assembly.GetManifestResourceStream(
typeof(RedistHelper), SqlCeRedistName))
{
Debug.Assert(stream != null);
byte[] bytes = new byte[(int)stream.Length];
stream.Read(bytes, 0, bytes.Length);
string path = Path.Combine(Path.GetTempPath(), SqlCeRedistName);
if (File.Exists(path))
File.Delete(path);
File.WriteAllBytes(path, bytes);
Process process = new Process
{
StartInfo = new ProcessStartInfo
{
FileName = path,
UseShellExecute = true
}
};
process.Start();
process.WaitForExit();
}
}
}
The only thing that really gave me a headache was referencing the System.Data.SqlServerCe.dll - it simply wouldnt IlMerge, so instead I loaded it on demand, in my main:
AppDomain.CurrentDomain.AssemblyResolve += RedistHelper.OnCurrentDomainOnAssemblyResolve;
Not sure if something changed or not. But with the latest SQL Server CE nuget package, the application manifests are no longer needed. You will get two sets of binaries: x86, and amd64. Just copy them to your target folder under x86 and/or amd64 sub directory.
|--Your App Dir
|--x86 (x86 sql ce binaries)
|--amd64 (amd64 sql ce binaries)
And you're good to go. Looks like the System.Data.SqlCe.dll can automatically find and load the native binaries. You can also deploy them in the app dir if your app is only targeted for one platform.