I need a little help on this subject.
I have a Web application written in ASP.NET plus I have the .bak file of the SQL Express database, my question is: How can I install this in a simple click and go way in the client?
how can I write a script that will create a new database, restore the bak file into that database, set up IIS and ... well, that's it :)
I do this all manually, and I do this a lot, so I was just asking if there is a way to prevent do all this steps manually.
Thanks.
You could use WiX to create a .msi that you can use to install your application at your clients. WiX takes a bit to get used to, but once you get the hang of it, you'll meet your needs above, and be able to extend them as your application grows or increases in complexity from the installation point of view.
I read your question to mean you have several clients where you install your application, if that is not the case, and your app exists in one place, there are better solutions, and better people to give them to you!
While WIX is certainly very flexible if you aren't comfortable with the learning curve (and there is a bit of a learning curve IMO) then perhaps you should check out the Web Deployment Projects.
From the blog post:
Web Deployment projects can be used with either the "ASP.NET Web Site" or "ASP.NET Web Application Project" options built-into VS 2008, and provide a few additional build, packaging and deployment options for you to use.
Regarding the database, I'd suggest that you utilise the App_Data directory and just deploy the ".mdf" file. This would be easier than trying to create a new database and restoring a backup.
Related
The product I’m trying to create a package out of is a Web Application and a Database Project. This Package needs to be deployed to multiple IIS Web Sites which individually has their own application pool and bindings. In the end I would want the package to be built by a TFS Build Server into a .zip file which via msdeploy.exe somehow can be deployed to these web sites by settings the web site, application pool, binding and destination database in deploy time. It should create if items does not exists and update if they do.
I’ve been researching quite a lot on Web Deploy 3.0. Most of the stuff I find on the internet via google is about defining the package and publishing from within Visual Studio which is not exactly what I want because I want to be able to have control over the settings at deploy time.
So far I can create a package relatively simple via the Publish dialog in Visual Studio 2013. I can even add my SSDT project dacpac file to the package using the “Update Database” checkbox in the Publish window. But I think a lot of things happen behind the covers which doesn’t seem logic how to do manually.
Ultimately the questions I have right now which I hope someone can help me with is:
How do I define dbdacfx settings in deploy time when deploying a
package? (Ie. Target sql server, database, username and password.) Or
can I parametrize these settings somehow into a parameter.xml file?
Can I use the publish profile xml file from my SSDT project?
How do I make my package create a new web site if it does not exists?
I can only find information about creating applications under already
existing sites.
When and if I create a web site via the package, how do I define the
associated application pool? Like creating it if it doesn’t exist or
update it if the target framework is incorrect?
I’ve read about providers. For instance appPoolConfig provider but
how to utilize this at deploy time isn’t very clear to me – can
anyone elaborate or perhaps point to a source explaining it?
Is there any good books covering this area or perhaps even a better
alternative?
I have an ASP.NET application and i selling it to different companies. I change the application settings according to the company information and publish the whole application to a output folder. And then take the output folder to clients machine with necessary dlls(My application dll and few third party dlls). I am wondering if it is possible for anyone to decompile the code from the dll's in bin folder and get the application code? Is there any standard process i need to follow so the my code are safe in client server.
You would need to obfuscate the dlls created for your project, but there are some issues with that related to ASP.NET. See this stackoverflow post
Enjoy!
Yes.... And see other answers for how to avoid it.
You can also try Redgate's SmartAssembly
Rather than Xcopy deploy, you should look have a look at web deployment projects for your deployment - http://msdn.microsoft.com/en-us/magazine/cc163448.aspx.
If you need to protect your assemblies from reverse engineering, you need to look at an obfuscator like http://www.preemptive.com/products/dotfuscator/overview
I've Googled, Binged, and here at StackOverflow, looked through the related questions and searched, but I'm not finding what I'm looking for. I've also searched documentation on DNN.
What I'm looking for is any guidance (tutorials, blogs, step-by-step instructions for setting up a repository) etc from people who are experienced in using DotNetNuke with SVN.
We use SVN for all our source control, and have no problem with standard applications, because we pretty much built the repository and directory structure to work with our processes. This means when we do web sites, in Visual Studio, we do file based web sites, rather than setting them up in the local IIS. It just makes things easier for us.
However, with DNN, it appears that even if you get the source code, it is expecting to be set up in the local IIS, which means additional headaches for us.
For example, we are moving all of our source code off our local C drives, and onto a shared drive on a server. This is to enable backups in addition to our normal source control. (This was a management decision). So that means that we need to change the virtual web app when we make the move.
Has anyone come up with a good way to work around this? Can DNN be set up so that the developer web server in Visual Studio can be used, so that we can treat it just like any normal web app? Am I missing something obvious?
Source Control
I recommend using separate projects for DotNetNuke projects (skins, modules, providers), and not checking the actual web site itself into source control environment (DNN Modules would use the WAP style project). Each developer could then have their own DotnetNuke site and database in their development environment. I also don't recommend making changes to DotNetNuke's core so that you have a clean upgrade path. I would recommend using a tool such as Red Gate's SQL Data Compare in order to generate database scripts for your data that you could keep in the source control environment as well.
Here is some more information about setting up a Web Application Project for a DotNetNuke module.
Testing/Staging/Production
Keeping these separate in DotNetNuke is generally very easy because you're already creating modules that plug into a DNN site. My recommendation is to create packaged and properly versioned modules so that you can cleanly install them on test, staging, and production.
You may want to investigate building module packages with MSBuild scripts. Alternatively, Here is some information on using NAnt to automate DNN module packaging.
I want to update an ASP .NET web application (including web.config file changes and database scripts) to multiple production environments - ideally with the click of a button. I do not have direct network connectivity to any of them. I think this means the application servers will have to "pull" the information required for updating the application, and run a script to update the application that resides on the server.
Basically, I need a way to "publish" an update, and the servers see that update and automatically download and run it.
I've thought about possibly setting up an SFTP server for publishing updates, and developing a custom tool which is installed on production environments which looks at the SFTP server every day and downloads application files if they are available. That would at least get the required files onto the servers, and I could use xcopy/robocopy and Migrator.NET to deploy the updates. Still not sure about config file changes, but that at least gets me somewhere.
Is there any good solution for this scenario? Are there any tools that do this for you?
I think the pull rather than push strategy somewhat flaunts conventional wisdom... but this seems like something CruiseControl.NET could easily do. Remember the web.config file is also an XML document, so is easily modifiable in a CruiseControl script. You could xcopy files or use an svn export.
http://varunkumargoel.blogspot.com/2010/03/how-to-make-automatic-deployment-for.html
Please view the above mentioned blog there i have posted details regarding automatic deployment of .NET application with SVN.
I'm working on a fairly new project and we started from scratch. So not only the web application itself needs to get developed, but also the whole process of publishing the site and configuring the web server etc. need to be done from scratch.
This question might be more apropriate for serverfault, but that really depends on the answers. So, let's give it a try.
Wehn ever I publish our site via VS2008 (right click on the web site, publish web site, wait... done) I need to somehow tweak the process and trigger some other tasks, like:
- Copy some folders from my dav machine to the web server
- Delete the test database and let some scripts run on it
- and maybe some more I'm not remebering right now.
I was reading about the most obvious solutions like MSBuild, Powershell and VSTS2008, but I don't really want to dive deep into them until really I know, that theses tools can actually solve my problems. So guys, I'm pretty sure a lot of you have got a lot of knowledge about these tools or know even better ones. Please let me know. I really appreciate.
Thats my environment I'm living in:
- VS 2008
- VSTS 2008
- SQL Server 2008
- Windows Server 2008
UPDATE: Thanks for the great answers so far, but I'm especially looking for a solution integrated into Visual Studio Team Foundation Server as we're already using it for Source Control.
Cheers,
Steve
We deploy our web application with Subversion, and are very happy with it.
The build server compiles the application, copies it to a deploy directory and checks in changes to a Subversion repository. Okay, I admit that this is not trivial, but it's worth to invest here... because on the server(s) the deployment is now extremely easy. Advantages are:
Only the necessary files are copied to the server, the downtime is minimal (using svn update)
It's a piece of cake to verify what version is deployed to the server, and it's easy to have a consistent version across multiple web servers
If you screwed up, it's just 2 clicks to revert back to the previous version
It's takes care of deleting files when you deploy a new version. Copying a web application over an older version can leave potentially dangerous files
Modifications in the web.config are not overwritten by the deployment, they are merged. That's really a big plus
You can set pre and post build events, and can have one the events fire a script to complete your tasks.
You might look to see if the IIS Web Deployment Tool fits your scenario; it allows you to publish your website, configuration settings, database, etc... all together. This will also be integrated into Visual Studio 2010.