I strungle with the deployment of an application which uses the latest entity framework together with SQL Compact with code first.
I want a zero deployment, means, on the target machine nothing except .net 4 is installed, I just copy the assemblies and everything have to work.
The requirements are just:
Latest EF
.Net 4.0
Code First
SQL Compact
The location of the *.sdf has to be done in the code, not in the *.config file
I google for hours and try different "solutions" from several places, nothing worked. On the target machine I always have just a crash without any information whats wrong.
Did anyone know a step by step tutorial or something with met my requirements?
(Or have a working project ready to tryout?)
I have a blog post and a completed solution here: http://erikej.blogspot.dk/2013/11/entity-framework-6-sql-server-compact-4_25.html
Related
I am working on a d365 unified interface sandbox environment on a development project.
This environment was setup recently as a clone of the production d365 instance.
Today I have been adding some plugins and finding a strange issue. I can get the plugin code on record create/update firing no problem (I have pre operation create/update and post operation create/update stages defined and the correct code gets hit for each).
But the C# plugin code does not recognise any of the pre or post images that I have added.
In code when we check IPluginExecutionContext.PostEntityImages it does not contain anything.
Any of the pre existing images that were there already when the environment was cloned are firing correctly. We have a process whereby we name all of our pre and post images the exact same for every entity and I know the ones I have created are named exactly as expected.
In this example I have created a Post Operation stage Update plugin on the OOB opportunity entity with a PreImage defined against it but the code just will not recognise it.
Anyone experienced this before?
TIA
Occasionally the sandbox service seems to fail picking up updates on a plugin assembly. In those cases updating the assembly with a different assembly version (build or revision number) can help.
If not, I would advise to simply remove the complete assembly and recreate it again.
If you do not have an automated deployment process in place, follow these steps:
Create a separate solution.
Add the assembly along with its step registrations and images to the solution.
Export the solution.
Remove the assembly using the plugin registration tool.
Import the solution again.
I have previously used System.Data.Sqlite 1.0.85 with EF5 in VS2010 and it worked well and I came to really like the designer. On my new machine, I've switched to VS2013 Community and tried to get Sqlite 1.0.94 and EF6 running, but it's such a hassle and I'm starting to get really frustrated. I can't seem to get it running on my old project, which I need to work on, but only on a fresh one. Tried copying the old stuff, but it just stops working again. From what I've read, I'm not the only one having these issues.
I can connect to the database in the server explorer, but the connection won't show up in the Entity Data Model wizard. It did run once on a fresh project, but since I keep running into trouble, I'd rather switch to something else that actually works.
So my question is, what alternatives are there? It's for a small business application. Would LocalDb be an alternative? Are there any other good databases/providers (free ones) that work well with EF and have designer support in VS2013?
Thanks for any feedback!
LocalDb can be used in the dev environment and works really well. But it might be too limiting for production use depending upon your requirements. Another option would be to use SQL Server Express. But this again might have limitations in a prod environment. The following link gives you an overview of the features of different versions of SQL Server:
SQL Server Editions
Another option would be to go for something like PostgresSQL or MySQL but I haven't used them, so can't say much about them.
I have a web application which uses:
MVC3, Razor, C#, EF4.1, .NET4, MSSQL2008(local), SQL Azure(Cloud)
It reads data from DB, merges it and create an XHTML document.
When run locally(IIS Express/VS2012/Win7), it is fine.
When run locally in Emulator, also fine.
When run in WAWS, very speedy.
I am running .NET 4.0 in the cloud service, WAWS runs .NET4.5, this could be significant???
I have seen reference to compiled EF being great in performance. How do I compile my EF? I have a seperate EF Model Project for my DB access code which is compiled as a DLL into my Web Application bin folder.
EF performance issue, See:EF Performance Article
I have run the profiler in sample mode on my cloud service, and the LINQ/Entity lines seem to be the "Hot" commands, so it is EF related.
I would appreciate your comment on this please.
Thanks in advance.
P.s Now off to recompile my app in .NET4.5, and redeploy.
EDIT
Just redeployed using osFamily="4" and .Net4.5 and processing time reduced from 30 secs to 1 secs !!!!! Amazing. In runtime after deployment was still about 30 secs.
EDIT2
After change to .NET4.5 I got lots of "invalid Access to memory location" errors when invoking the full emulator. Not sure if this is to do with me running VS2012 or WIn7 with osFamily="4" in the emulator. see: Solution
I post this merely as a reference for others that might end up being in the same situation and since I spent almost 3 days trying to figure out the root cause of the problem, I thought it would be a good idea to post the solution here.
My situation was as follows:
I tried to build a deployment package for a .net application and got TypeLoadExceptions, FileNotFoundExceptions (regarding DLLs), Side-By-Side configuration errors, etc. once I tried to run it on a vanilla test machine.
[edit]: stackoverflow won't let me answer my own question within 8 hours of it being posted, the answer follows in ~8 hours ;)
The problem was that one of the dependency projects of my application was set to "Debug" build in the Visual Studio configuration manager, therefore the debug dll of the dependency ended up being used for release builds as well. On any development machine this was no problem after all since all debug runtimes were available.
On the vanilla test machine however only the release runtimes were present which caused so much trouble to me and gave me unmeaning exceptions that lead me to so many wrong directions via google, etc.
In my case it was SlimDX that was set to build a debug build in the VS configuration manager, even when doing release builds. Since SlimDX makes use of the VC runtimes I got the above problem, but this could happen with any .net assembly that uses the VC runtimes.
I hope this will eventually safe someone some hours ;)
I guess I should have thought of this before I started my project but I have successfully built and tested a mini application using the code-first approach and I am ready to deploy it to a production web server.
I have moved the folder to my staging server and everything works well. I am just curious if there is a suggested deployment strategy?
If I make a change to the application I don't want to lose all the data if the application is restarted.
Should I just generate the DB scripts from the code-first project and then move it to my server that way?
Any tips and guide links would be useful.
Thanks.
Actually database initializer is only for development. Deploying such code to production is the best way to get some troubles. Code-first currently doesn't have any approach for database evolution so you must manually build change scripts to your database after new version. The easiest approach is using Database tools in VS Studio 2010 Premium and Ultimate. If you will have a database with the old schema and a database with the new schema and VS will prepare change script for you.
Here are the steps I follow.
Comment out any Initialization strategy I'm using.
Generate the database scripts for schema + data for all the tables EXCEPT the EdmMetadata table and run them on the web server. (Of course, if it's a production server, BE CAREFUL about this step. In my case, during development, the data in production and development are identical.)
Commit my solution to subversion which then triggers TeamCity to build, test, and deploy to the web server (of course, you will have your own method for this step, but somehow deploy the website to the web server).
You're all done!
The Initializer and the EdmMetadata tables are needed for development only.