I am building a very small temprorary website that needs a small backing store. I have built this in ASP.NET MVC 2, and wanted to host with DiscountASP - although this isn't essential.
I would like an backing store that will work with ASP.NET MVC 2, VS2010 Express, enabled LINQ (or EF) and work without further charges on a shared host.
From my investigation, SQLCE 3.5 doesn't work in .NET 4
SQLCE 4, is only CTP and doesn't work in VS2010
SQlite doesn't have any .NET 4.0 drivers.
HAve I got this right? Any good tutorials or blogs that show how to get this working step by step?
Thanks,
Mark
SQLite does work on .Net 4.0. Here are some other very similar questions about embedded databases in .NET:
Good embedded database solution (like SQLite) for .Net
Embedded database for .net
Open Source Embedded Database Options for .Net Applications
I'm not an ASP expert but have you heard about Firebird SQL? Database engine which has client/server or embeded versions, fully featured with transactions etc. and with ADO.NET provider
http://firebirdsql.org/dotnetfirebird/
http://firebirdsql.org/index.php?op=devel&sub=netprovider
No, Dont even think about using firebird embedded in ASP.NET.
It is strictly forbidden.
here's a reference on Firbird website tell you to avoid:
Is it possible to use the embedded Firebird in my ASP.NET application?
Yes. But Firebird ADO.NET looks for the fbembed.dll file in the application working directory. For ASP.NET application the working directory is the system folder (e.g. C:\WINDOWS\System32). But it's not without problems
link text
On Another page from the same website:
ASP.NET uses a feature that help against poorly written ASP.NET application to block the entire server - it recycles the ASP.NET working process both regularly. By default, IIS6 uses overlapped recycling where there is a new process started before the old is stopped to ensure uninterrupted operation. The problem is that the fbembed.dll exclusively locks the database for the owner process so if you run another process simultaneously the database won't be accessible before the first process stops. You might want to accept this but it really is not an optimal solution.
The solution is to turn off the overlapped recycle (by setting the DisallowOverlappingRotation metabase property to true). However, this might cause outages of your application during recycle.
Conclusion
Don't do tha**t ;-). Really, fbembed.dll **was not built to handle such use. You can make it work but it is just a hack.
Related
I know such questions have already been asked many times, but I am here with my scenario. Kindly do not delete or vote to close.
I have an asp.net application with L2S and SQL 2008 R2 as backend
Using N-Layered architectured
Mostly normal crud operations to be performed.
Use of Sessions and View States
Manual Login / Logout(User and Roles management) , no .net Membership has been used.
No services used yet, might be a later part.
Third Party controls like Telerik or Infragistics also are in use.
I want to know:
Do i need to change entire application to Azure Web Application?
If not, is it possible to deploy it directly over the cloud , on MS or any other, as we normally do in IIS?
If not, Is there any third party migration tool available to make my plain old web application cloud-compatible, without affecting existing codes ?
I want cost effective and easy to go steps?
Thanks in advance
Yes that should be possible. You almost certainly do NOT have to change your whole application.
Linq2SQL is fine, I run an Azure site with L2S without any problems
You'll have to deploy your DB to a SQL Azure database. There are some restrictions, like all of your tables must have a primary key. A bigger list is here: http://msdn.microsoft.com/en-us/library/windowsazure/ee336245.aspx.
Also, when generating your SQL scripts, be sure to select SQL Azure as the database engine type: http://mooneyblog.mmdbsolutions.com/index.php/2011/09/22/generating-azure-friendly-sql-scripts/
What do your N-layers look like? If they are DLLs, it's fine. If they are web services, you'll need to create web roles for them. If they are windows services, you'll need to port them to a worker role.
Most crud and view state and manual authentication code is fine
For session, it depends on what you are doing (memory vs database). But you'll have the same challenges that you would have if you deployed to any web farm
For Telerik, I'm sure they have to have some support for Azure, and I don't think they would be doing anything crazy that would not work Azure. You should check out their website to verify compatibility.
Also, make sure you are not writing to the hard drive anywhere and expecting it to be there later, because instances can be started and stopped and reimaged at any point. If you're doing that, you'll need to change it to use something else like blob storage.
I have an ongoing series of blog posts that walk through some of the steps, which should help: http://mooneyblog.mmdbsolutions.com/index.php/category/azure/
Good luck!
I don't see any hassles to deploy your web application into the cloud.
You don't need to convert your entire application to anything else.
After all you can just try to deploy it now with the trial subscription in Windows Azure which is free for three months.
There is a fairly big stuff of new technology in Windows Azure such as service bus, azure storage, access control service, etc. However it's not necessary to use all them right now. It's prety easy just to move the existing app into the cloud.
You can deploy it to Azure web site.
That should be easier if you don't want to use SQL Azure and cloud storage.
I am using a really old website running on .net 2 but I am adding an addition to it that is MVC 3 running on .net 4, created as a virtual directory under the original website.
The problem is that if I get the "Server Application Unavailable" with one of the frameworks I can run aspnet_regiis for that framework and it fixes it but then it make the other framework give this error
I fix one it breaks the other
is there any way around this
I need this asap, client is breathing down my neck
Just create two application pools targeting each respective framework.
IIS does not support running multiple .Net frameworks within a single application pool. If an application requires a different framework version than other applications in the same application pool, it must be placed in a new application pool.
You need to use different Application pools for each of the framework versions.
You have three choices:
Upgrade the existing site to .net 4.
This might be a lot of work.. or it might not.
Start over with your "additions".
This time using the same tech as the site is built in. Without knowing how involved your additions were, this might be easier than #1.
Create a new app pool just for your 4.0 site.
This item has the caveat that you aren't going to be sharing session data between the two. But may be the most expedient. Given that you are just now finding the problem I'm going to guess that the addition really isn't that tightly integrated and so you'll probably be just fine.
Either way I hope the lesson you take from this is that using new trinkets on an existing site is probably not the best way to go. ;)
I am currently maintaining an in-house business tool for our company's timesheets and project information. I need some general advice regarding web languages and best practices.
Details:
Runs on Windows Small Business Server 2008
Combination of Classic ASP, JavaScript, CSS and Javascript
Access database backend
Large system, containing around 135 pages, of 2.3 MB total
Objectives:
Extend functionality in small ways
Possibly move to different languages to ease maintenance (AJAX?)
Separate code from HTML structure (currently VERY messy)
1) Given that I don't have a lot of time to entirely rewrite the system, is it sensible to keep going with ASP and JavaScript?
2) I've had a look at some AJAX and it seems like it would be an easy leap to include it in the page, is this an avenue worth pursuing?
3) Is it worth investigating an MVC framework? If so, does this need to be done formally with some kind of library, or are there best practices I can follow to implement MVC functionality using ASP?
4) How difficult might it be to upgrade to a 'real' DBMS such as MySQL and port the database? Is it worth doing? (Feel free to smack-talk Access)
Sorry for the length, I'm just a little lost in the giant multitude of Web standards, languages and practices.
1) For the javascript part take a look at Jquery. Normally this cuts down old javascript code to 1/10 of size and a better separation of ASP/HTML Code and JS Code. Ajax comes for free and it has a really good plugin ecosystem.
3) From my experience porting such a big system is not a good idea.
ASP Classic runs smoothly under IIS 7.5 ans IIS Express so you can take the good parts like Url Rewrite and other IIS plugins. If you need more power in your ASP classic pages simply combine them with ASP.NET pages. It is no problem to run them side by side, I usually use ASP.NET generic handler (.ashx) if I need the power of the .NET Framework to complete tasks like dynamically generated Zip files for example.
4) Upgrade to Sql Server Express.
Microsoft SQL Server Migration Assistant (SSMA) will help you to convert the Access DB to SQL Server. I've done this before with a 1 GB (no binary data) 200+ tables database and migrated the old ASP system in a week to SQL Server.
With Jquery, IIS 7.5 or IIS Express, .Net Framework 4.0 and Sql Server 2008 Express you can "pimp" your system in much less time than porting it completely.
Seriously, if the thing works and performs for you as is, then I'd "extend the functionality in small ways" and possibly add in some Ajax, if you think it would offer enough value given you limited time.
I'd certainly not consider porting a 135 page application just for the sake of porting it.
Access has its issues, but if you're not running in to them, I wouldn't take the time now to convert it.
Can I convert a non-MVC asp.net application to be Azure compatible ? Or If i want to create an Azure web application, should it be MVC one ?
The other answers answered your question about converting your app to MVC for deployment to Azure (you don't need to).
If you're creating a new web application and go with ASP.NET MVC (which I'd recommend), just remember if you go with MVC3, you may have to make some of the MVC3 DLL's CopyLocal for your deployment, as it won't be part of your web role instance. At least that's how I still understand it. The 1.4 SDK of the Azure SDK doesn't have a MVC3 Web Role template yet.
See this post on steps to get your MVC3 app Azure-ready.
Hope this helps.
You may take a look at the following blog post for migrating an existing ASP.NET application to Azure. It should not necessarily be an ASP.NET MVC application. Any ASP.NET application will work.
azure has 2 roles
1. a webrole
2. worker role
web role is nothing but an asp.net app. so no need to convert it into an MVC app just any asp.net thing will do fine
Yes, you can. But you need to be aware of certain limitations too, none of which were mentioned in the answers already given:
Your application should be stateless, unless you are running a single instance (for most apps 99,9% reliability is OK, but there are some where you want 99,95%, so you need at least two instances + it gives you additional benefits of a load balancer, etc.). The reason for this is that if you have more than one instance, the load balancer will deliver the request to a different instance. You can use AppFabric Cache to solve this.
You don't have a file system - this is not entirely true, but in reality you should never rely on having local files. All you image uploads (e.g. user profile pictures) should be uploaded to a blob storage and linked to there. How you do this is another matter, and one that can be approached differently depending on the architecture of your existing application. You can get away with files, by using Azure Drive, but it's slow as hell.
No Event Log / RDP - this is also only partially true, but you should rely on other ways of getting diagnostics information from your role. While you can RDP to your role instance, there are better ways (e.g. Azure Diagnostics storage).
Database should be chosen carefully. Sure, you have SQL Azure available, but it's expensive (1 GB = 10 USD/ month). If you can get away with stuff like Table Storage, you may save on some costs. Again, this depends a lot on the architecture.
As for the second part of your answer. MVC as a pattern is nice. It saves you a lot of time, it's much more adapt for the Web as WebForms ever will be. The event based system was designed for Desktop applications, and it was forced onto the web. However, going to Azure does not imply a requirement to go to MVC. What I suggest you do however, is treat it as a nice jump-start opportunity to look into MVC and see how it could help you write your apps better & faster.
As with any other case involving architecture of apps, it depends. If you used common patterns (e.g. IOC, Repository), you will have a really easy time moving any app to Azure.
I have been tasked with a project where I am to add a new application and have it within an older application (web applications). This is an internal application and management decided that they want it wrapped in this older app. The older application is a ASP.net web app using the 3.5 framework.
My original plan was to use jQuery and Web Services (using JSON and AJAX). My team-mate on the project really wants to use Entity Framework (4.0). As we may be sharing the same look and feel the data is a different database altogether.
After several attempts yesterday, we found some issues. We created a project inside the original solution that targets the 4.0 framework. I created a WebService on the project, but when I tried to call the webservice from the 3.5 project I didn't get an error but I didn't get the return string. I was watching on Firebug and did not see the GET call either.
My team-mate did a little more research and found out about the cross-domain issue and jQuery, so it seems that we are limited with the Entity Framework (3.5) and remaining on the .net Framework (3.5). We did try changing the dataType to jsonp but calling the WebService still didn't work.
However, I was wondering, really management wants the project wrapped inside this other project for consistency sake (navigation, design and so forth). Is there a way to have the 3.5 project display our code that is being generated from the 4.0 project (a totally different solution and probably a different server)? I'm thinking the way the iFrame used to work but I don't want to use an iFrame at all.
One way to solve this problem would be to stand up a WCF webservice to handle the database calls. You could develop your "data layer" with .NET 4 and EF4, then call that layer from your .NET 3.5 ASP.NET application. It's not the absolute cleanest solution, but it would allow you to get the benefits of the newer version of EF.