I have a Visual Studio project that has different Windows Forms and a SQL Server database attached. I want to install this project on my client computer (others). As I haven't published any project before, can someone guide me in an easy way.
When I tried to publish (installed) this project in my computer (setup file would be created and the application would be installed but) but I get the error shown below while saving update delete data. Please guide me correctly.
You are taking a completely wrong approach here.
Databases are not meant to be installed in client's computer. If you have a client/server app, the database should be located only in your server, and the client will access it/request to write into it by sending requests over a protocol like TCP, which your server will react to.
When you add a database to an app, you provide a connection string and this connection string is related to YOUR instance of the database. If you wanted every client to use a unique DB, you'd need to go over to their computers, install a DBMS, create the database there, then edit the program code to include the connection string for the specific client instance. Obviously this is not a viable option unless the clients you're talking about are just like your immediate family/roommates.
If you intend to provide your clients app with saving/reading data functionality, you'd need to implement it by having the data written into a local file which the program will be able to read from, such as a csv or a tab delimited file. Not through a database. At least not SQL server. If you're completely obligated to use a DB, then think about an embedded, serverless DB like one from SQLite
The reason you're getting that error is because the client's program is trying to look for the database instance that is indicated in the code, but of course, this instance does not exist in the client's computer, so the client cannot reach it to do anything.
Also, please remember to use exception handling. We cannot tell what the exact error was (although it is obvious) because your code is only saying "an unhandled exception happened". Always wrap your code In try/catch blocks and at the very least have them print the exception to a console so that you can know WHY did a program failed on runtime.
Related
I was wondering what would happen to a program's connection to the database after compiling it to setup.exe? Will the data from the server explorer be saved somewhere after producing a setup installer so it could dynamically be changed later?
I'm still a bit new in coding. Just barely started.
So I'm not really sure if my questions would make any sense to all the experts.
I hope someone could enlighten me.
Thank you.
It all depends on what form of Database and what settings you had in your project.
case 1:
you are using a server-client Database. Server-client databases are like Sql-Server, MySql, Postgresql, Oracle.....
Usually they have a host, username, password and/or authentication method.
In this case, and while you are configuring your database with in your project in visual studio, you can choose to save the connection string with in your configuration file resources or hard code it in the application.
The Data will stay on the database server.
Case 2:
You are using one of file Database solutions like Sqlite, VistaDB, Acess DB file, XML based DB files, Sql-Compact SQL-CE (obsolete and replaced with SqlExpress)...etc.
In this case, the DB file (which should be in your project file and you have chosen from visual studio the option of (copy if newer)) will be included with your project with the data in it. You have to be sure in this case the proper assemblies are present with you your application *.dll. Your installer have nothing much to do here unless the DB solution you have chosen said other wise.
For example, if you used SqlExpress your installer should be sure that it is present when your user installs your application and if not it either installs it or instruct the user (at least by providing proper links) the methods to install it.
As for the connection string it takes the same conditions of case 1.
Hence you tagged your question with #sql-server I will assume you are looking for the SqlExpress case.
If that's the case I will refer you to the couple of links which will provide you with further details:
1- How do I connect to an MDF database file?
2-How do I connect to an .mdf (Microsoft SQL Server Database File) in a simple web project?
3-C# - Connect to MDF database
4-THE ‘CONNECTION STRING’ STRING OF CONNECTION WITH DATABASE. AN EXAMPLE OF USING IN APPLICATIONS
Finally remember web search is always your friend:
5-c# sql server connection string attach database file (in google search)
I'm very new to App deployment. This is my first one actually.
I developed an app which uses a SQL Server database to store its data. I created the SQL Server database with a script. However, neither the script nor the DB itself are part of the "package" of the app. I simply installed SQL Server Management Studio with the default settings, created a new file starting with
USE [Master]
GO
CREATE DATABASE [Database]
and filled up all the details.
The app works in my machine of course, but when I Published the app and got the .Exe, it doesn't work in any other computer, of course because it's not creating a Database to go with it, and the connection string that it uses for the queries is the one that I gave it from my SQL Server instance.
So, I want to know how to actually include the database (or a way to create it) in the "installation package", and also for the program to dynamically get the necessary connection String to operate on any computer where its installed. Right now, I AM fetching the connection string from App.Config with the ConfigurationManager, but of course, the Connection String in App.config is the one that got added when I added MY instance to the project.
Any sort of guidance would be appreciated. I searched related questions but the only ones relevant had some deprecated methods. It's still not very clear to me how it would get the connection string dynamically if its not going to be the same instance.
On a semi-related matter...I noticed that my app was being executed with just double clicking on "setup.exe". Setup seems to imply that it will only install it and add an executable...it's kind of misleading to execute the app itself from the setup, isn't there another way to change that?
I know this is kind of a stupid question but it gives me a lot of problems. Me and my partners in college projects have a lot of issues making the database mdf work when we send each other the visual studio projects. It gives us errors about the versions of sql server. Is the only solution to this to install same version of sql servers for the entire team or is there some other workaround?
Yes, you must be using the same version of SQL Server across all PC's.
You can never "go back" in time with a SQL Server database - once a .mdf file has been attached to a given version, it can never be attached to an older version anymore. And you cannot get around this by using the database compatibility level, either - the internal database file structures are just too different between versions, and no backwards "downgrade" path is provided.
One way to get around this would be to have a common, shared server somewhere that everyone can connect to and everyone can work with - making in unnecessary to send around "free-floating" .mdf files altogether... after all, it's SQL Server - a server-based system - not so much a file-based "database" system ....
Another way to go would be to stop sharing the binary .mdf file, but instead work with SQL scripts that you can exchange within your team, and that each team member can execute locally on their respective SQL Server instances - regardless of their local version
I suggest that instead of passing around mdf files, every person on your team creates the DB and then uses SQL scripts to create the objects. These scripts can be very easily created and exported from the SQL Server Management Studio.
This has the added bonus of being able to put the scripts under version control as part of the project.
I made such practice, with one way , by create separate pc running under windows server, only using as sql server to store all data record , then the data is called via "connectionStrings" of IP with server name of user policy, which is also secured by password and username , so this practice is used , to enabled two different programs to share that data , for example , that I made ( one web localhost app to create internal registration ),( the other web app using to access to mainpage via Login form).
Is there anyway to prevent people from using Reflector.net to decompile my .exe c# application? I know there is a tons of post about this but I don't really care if people can see my code the only thing I want to "hide" is my database connection string.
I am currently using "Settings" in my c# to keep the database connection's info.
I wanted to know if using those string in my project's Settings would prevent people from seeing it ?
I am using DotFuscator in visual studio 2008 but I heard it wasn't preventing people from decompiling my program.
I know I could use a Web Services but my server will be on linux so I guess I can't store web services on Linux.
No. Even if you encrypt the connection string in the program code or in a settings file, you will need to decrypt it, and the program must necessarily contain the decryption key somewhere, which means that someone who is interested enough in finding it will find it, no matter how creative you are in hiding it. Why do you need to hide the connection string? If you are afraid that someone who has your program might call the web services directly and trigger unintended actions, you should look into how the web services are structured, what they allow clients to do, and how the authorization works, and make security improvements there instead.
If your program has the connection string in it, users of your program can get it back out. Even if you encrypt it, they can sniff it when your program connects to the DB server.
If you don't want your users to know your DB login credentials, don't give your DB login credentials to the users. That's the only way.
You could do this by instead giving each user their own credentials, and using the permissions system in the DB server to control what they can or can not do.
As others have stated obfuscation is no real protection for a connection string stored in a client application where the user have access to the binaries.
Don't use a direct database connection from your program unless the user is trusted to use the database directly with the same privileges. Have a service (web service, REST-service, etc) in between that you host on your own server. Linux can host services of any of those types I mentioned (use Mono if you want them in .NET on Linux)
In order to expose your database via a web service using Mono or any other language/framework you can host on Linux you would create a web service method for each atomic operation you want to perform against the database.
An additional advantage over letting the client application access the database directly is that when the client application is using a service between itself and the database you are free to change your data store without affecting the client. You can decide to change the database schema in your database or replace the database with a NOSQL solution or even a flat file.
Having a service instead of communicating directly with the database moves the authentication/authorization requirement one step, so now you need to implement it in the service. Fortunately there is rich support for authentication in a web service.
Take a look at this guide on this specific topic from MSDN. Keep in mind, however that this only shifts the security burned. Now you need to manage the security of the key
How can I make a program use a SQL Server database, and have that program work on whatever computer it's installed on.
If you've been following my string of questions today, you'd know that I'm making an open source and free Help Desk suite for small and medium businesses.
The client application.
The client application is a Windows Forms app. On installation and first launch on every client machine, it'll ask for the address of the main Help Desk server.
The server.
Here I plan to handle all incoming help requests, show them to the IT guys, and provide WCF services for the Client application to consume.
My dilemma lies in that, I know how to make the program run on my local machine; but I'm really stumped on how to make this work for everyone who wants to download and install the server bit on their Windows Server.
Would I have to make an SQL Script and have it run on the MS SQL server when a user wants to install the 'server' application?
Many thanks to all for your valuable time and effort to teach me. It's really really appreciated. :)
Edit:
To clarify, each business will have their server completely separate from me. I will have no access whatsoever to them nor will they be in any way connected to me. (I don't know why I should clarify this :P )
So, assuming the have ABSOLUTELY NO DATABASE SERVER installed; what can I do?
Ok, part of the answer, dealing with the SQL Server Database (and frankly SQL Server Express will take you a long way - 4Gb of data) and the server install elements.
Firstly make installation of the SQL an SEP, make it a pre-requisite possibly tweak your installers to test (challenging) but substantially point them at the links to SQL Server express and let them get on with it).
Secondly separate installers, as suggested, for your client and your server elements.
Finally, how to build the database - I'd suggest using code to create and maintain (update) the schema i.e. once you have a connection to a server you can run code that calls DDL that does what is necessary (something like suggested here: How to create "embedded" SQL 2008 database file if it doesn't exist?)
A question - are you intending all communications from the clients to go through you WCF service?
Your install application should:
Obtain a SQL Server name, a username (with apprpriate rights to create a database) and password.
Either run SQL scripts using the locally installed command line tool or from code using SMO (for instance), against the user supplied server with the supplied credentials.
BTW, Before you expend effort writing an open-source help desk, have you checked what is already available? Also, Open Source Helpdesk
It is not so straightforward to deploy a client/server solution with an automatic installation.
You probably would then be better off to deploy your server installation together with a database engine and a skeleton database already setup according to your wishes. This is to avoid tampering too much with the existing server - who knows whats on it.
Also you say you want to install WCF services, well this would probably mean installing them on a customer server, in theory this shouldn't be a problem however in reality it could be, depending on what is previously on the server.
Do you want a single SQL Server instance running on your machine, or one on each of your customers' servers? If it's the latter, you'll want to install a SQL Server instance - anything from the (free, but limited and not open-source) SQL Server Express to a more expensive SKU - on each server. You can include this step in your server installation package; MSI installs make it very easy to bundle a MSSQL install.
Then you'll need to drop a schema, and maybe data, on the instance. You could do this as a step in your installer, or as part of your application setup process. It possible that a SQL Server instance, or more than one, might already be installed on the server, and your post-install step should allow the user to specify which instance on which to install your pieces.
Then, include a database configuration piece in your client application. Ask the user - or take from a configuration file at client install time, to allow for unattended or unprompted client installs - server connection details, like server name and authentication information.
A word on authentication - since you appear to be building Windows-based tools, use Windows integrated (domain-managed) authentication if at all possible. Don't get in the business of storing logins, but instead rely on the existing domain to manage logins. A good strategy is to use active directory groups to manage access. Grant access to a particular group in SQL Server, and defer group membership to Active Directory itself. If you can't gain the access necessary to do this, then grant permissions to AD user accounts themselves. Avoid creating SQL Server logins, the use of which open the door to some possible security problems.
I understand what you are trying to do. If I were you, I'd do the following:
Provide 2 downloads - 1 for client and 1 for server.
Forget about MS SQL Server and perhaps go with MySQL, since it really is open source. You could probably get away with using MS SQL Server Express Edition, but if your data set gets gigantic large (which is common with help desk databases), you'd be stuck.
As other people pointed out, on very first run (or at setup time), I'd have the client app locate the server.