I'm developing an asp.net web API, the functionality of the API depends on saving files, in my older projects i used to save files base64 string in SQL database, but currently I am trying to save them as files on the server and save the URL in the database, I am using iWebHostEnviroment with the root directory to save files in it, it works fine. My Question is if this is the right place to save them, i have never deployed API on server before so I am afraid that it's working only locally and after deployment it won't get the right directory on the server it self
I tried webHostEnvironment and HostEnviroment and all the returned paths are local paths on my pc, idk if this would work on actual server or i should save them somewhere else in the project
Related
I've completed a Java project with Hsqldb, the application works fine on my local machine, this is intended to be used as a standalone desktop application on the Windows platform. Please could you suggest any references/documentation on how to go about the deployment processes. Thanks in advance.
For deploying an embedded HSQLDB database, the only thing that can be different on the target is the location of the database files.
You define the directory where files are stored and it should be a writable directory. In this case, define the path and use it as an absolute path (which includes the drive name if any) to connect to HSQLDB.
You can also define the database connection URL to contain the user home directory path. This allows storing the database is a subdirectory of the user's home directory. See http://hsqldb.org/doc/2.0/guide/dbproperties-chapt.html#dpc_variables_url
I have an ASP.NET Web Api project which has App_Data folder. Inside of it I have a database file(.sqlite) which I use in my application. There's a connection string to it that resides in my configuration files. The path is absolute and includes my current file structure(C:\Something\Other\App_Data\MyDb.sqlite). The problem is that I want to host it on Azure and most likely Azure won't find this path. So, for that purpose I would like to use a relative path so on Azure the file gets properly located.
Within your server side code (C#, VB.NET, etc.) you can use: ~/App_Data/.
If you are trying to reach the directory within a connection string you can use: Data Source=|DataDirectory|DatabaseName.sdf
If you want to use Azure web app with single instance, please try the connection string that Jesse Johnson provided. If your web app need scale across multiple machines, I think SqlLite is not suitable for you to use. Azure Web App ARR will dispatch the request to some instance, and your data will saved to this instance via SqlLite. If next time the request is dispatched to another instance, I think you could not read the data you saved before. I think it is better to choose Azure Storage or Azure SQL to save your data.
The root issue is that we have an ASP.Net application with a deep folder structure that we run within the Cassini web server and install on customer machines using a ClickOnce deployment. However, ClickOnce imposes limits on file path lengths which is starting to cause our deployment to fail. There are also a bunch of other issues with ClickOnce (e.g. handling of binaries in the web-app's bin folder) which we have solved via 'creative' means (i.e. hacky), as such we think a nice way to side step these ClickOnce issues is to deploy the ASP.NET app as a single zip archive. To Do that Cassini and ASP.NET would need to be able to the ZIP archive as a virtual file system.
One method might be to mount the zip archive in the file system (e.g. mapped to a new drive letter); The concern there is that some customer environments will likely prevent the application from mounting a new drive.
Ideally then we're looking for some means of representing a zip as a file system that we can point Cassini and ASP.NET to, but that isn't being done by the OS.
=== Update ===
Possible options:
Unzip to a temp folder and point to that folder.
MSDN article: Virtualizing Access to Content: Serving Your Web Site from a ZIP File
I am developing an ASP.NET website. I wanted to shift whole of my work to another PC of mine. I copied the website to the other PC>Open>Create ASP.NET folder>App_Data
and pasted the database.mdf and database.ldf files there. I was getting some exception when I was trying to run the website as it showed the "could not open the connection from con.open()". Is there some other step too that I am missing?
Sql Server database files are not like any simple html files that can be copied between machines. You need to make sure that the database that is getting served up: e.g. there is a Sql Server instance running that can present the database to your web application.
Here's an article on how to attach an mdf file to a Sql Server.
You need to attach the mdf and ldf files to the sql server instance on the target machine. You may need to adjust your connection string as well, unless you used a local name reference like "." for the data source.
What is your connection string? Chances are the path in the connection string has the local path to the database file on your original development machine.
When creating a new database with SQL Server Express 2005, the database files (.mdf and .ldf) get stored in C:\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Data by default.
However, with the tutorials I've seen for ASP.NET MVC (e.g., Nerd Dinner), it seems to be common practice to keep the database files in the ASP.NET project's App_Data folder.
Questions
Is there any significance to the App_Data folder, or is it just a convenient place to store database files if you happen to use Visual Studio's designer to create a new database?
Will there be any negative repercussions if I don't use or even delete the App_Data folder?
Update
One thing I'm still not getting. If you have a production database on the server, why would you even want to replace this database with what is in App_Data. Wouldn't you normally just want to have update scripts that you run on the production database when you release a new version of the app? Even for initial deployment, I'd rather script database creation than physically copy over the files. Also, with SQL Server (Express) databases, copying is not enough. You have to detach the database to manipulate the files then reattach when you are done.
So, I have to say, the point of App_Data still escapes me. Can someone enlighten me?
You can delete App_Data without any negative repercussions, but when it exists (by folder name) inside an ASP.NET website then it has the special website power of disallowing direct linking to download its contents - this is a security feature to protect your database from being downloaded directly over the web (e.g. by a web browser) even though it exists in the website. However your application can still access the files in the App_Data folder just as it accesses other website content.
Microsoft states it as:
Note: The content of application
folders, except for the App_Themes
folder, is not served in response to
Web requests, but it can be accessed
from application code.
Microsoft describes their special ASP.NET folder structures including App_Data here.
There are a number of advantages of placing database files in the App_Data folder:
As some have mentioned, that folder is secure from people browsing it directly on the web. This is also true of placing the database in folders outside of your web site, though.
You can "xcopy deploy" your application by copying the entire folder from your local development machine to your hosting web site.
Various components in Visual Studio can offer extra assistance in building your application by having your database files there. For example, you can double-click on a SQL Server Express MDF file and have it automatically open up in Server Explorer so that you can change the database's schema or view its data.
There is absolutely no need to use the App_Data folder. It's just a convenient place to keep your database files together with your site. The decision to use it or not is more a matter of preference / policy than anything else.
yes, when you are simply using an express database which will exist within your webroot it is best to use the app_data folder. The primary reason is that the asp .net isapi implicitly knows not to fulfill any requests for files from this directory. The same goes for the app_code folder. There is no stipulation that you have to but its good practice to be prudent.
You can also store sensitive xml,access dbs and any other data files in here for added security.
I've only ever used it for local development before pointing the web.config at a SQL server instance rather than the db files.