Let's assume I'm going to create project in ASP.NET MVC 4 and users should be able to easily switch between test/demo database and production one. Both databases will have same schema, but different users and data.
Should I simply use two versions of web.config with different connection string and deploy it to two separate IIS instances?
I thought also about choosing database from dropdown list during logging in, so I would need only one IIS instance and one config with two connection strings. Do I gain anything from latter approach other than more complex code to handle it?
In our system we use web.config transforms and use MSDeploy with Publish Profiles in the project for our two different servers, Dev and Production.
To deploy to Dev, you simply click publish and select the "Dev Server" Publish profile and out it goes. Same thing on production, but you select "Production Server" from the publish profiles.
Dev and Production are two different physical servers, which is ideal. What if you do something where you need to reboot the dev server to test some big changes, or some new updates etc, you don't want production going down with it.
Our environment is virtualized so it was easy to create a production server and a dev server. Really we created a dev server and once done, we based production off a snapshot of the dev server, so they are basically identical with different code bases.
We also setup Visual Studio Remote Debugger on both servers so we can debug code without having to install visual studio on them.
Being on two different servers, they have different urls, e.g.
something.com
login.something.com
admin.something.com
dev.something.com
dev.login.something.com
dev.admin.something.com
Now, we also use twitter boot strap and out design has 2 columns on the left and 2 columns on the right for spacing. So when on the dev server, I render giant "DEV" images vertically in the column spaces.
I should also mention source control. We use SubVersion for a source control server and Tortoise SVN with the Visual SVN VisualStudio extension to keep our projects in source control.
It's setup to the point that any developer given access to the code can to a Get on the repository and open it in visual studio 2013 and click publish. The code is very easy to move from developer to developer.
We also have some versioned assets the site uses and we have the dev/prod servers setup with Tortoise SVN as well. E.g. EmployeePhotos are in source control, and a developer can add new photos to SVN and go on the server and go a get on the virtual directory containing them and they are uptodate. Handles deletes as well. If we delete a folder from source control and do an Update on it, SVN deletes the deleted images.
All code aside, I would host the two separately. The chance of someone screwing up production data when they think they're messing with test data is high enough that it's better to have explicitly different URLs. I'd even probably have visual cues in your Master layout (color differences, differences in the main page header,etc) to make it clear to the user where they are and what they're expected to do there.
Even if you're not worried about that per se, you're right that managing it internally will be more complex as well, and error-prone. I'd steer clear of it.
Related
I have a webpage that offers an installer which adds an registry into user's computer based on the clients that the user has access to.
The installer is quite simple. It reads from its app.config, gets the client key and downloads configuration file that is used to create the registry.
Here is the thing, I use ClickOnce to deploy the app. The main logic of the installer remains the same, the only different thing is the app.config key. If the user has 5 clients, I have to publish 5 times since I separate different installers by setting different publish/install urls like below. BTW, I will have to define different Assembly Name too:
It's definitely not a good solution.
Is there any better ways that I can configure the installer to accept this parameter from the webpage, or other better ways to automate this process and then reduce the publish times?
Looking forward to any suggestions!
Thanks!
What I finally done is to write a powershell script, modify related parameters in csproj and deploy them. But I failed to copy those deployed files to remote server(aws). If anyone has any experience on that, you're more than welcome to share your thoughts!
We're developing a custom Content Management System in ASP.NET 4.0, using Team Foundation Server for source control. The database is hosted in a remote server, whereas the debug is done locally, thus new content (aspx pages) created by each member of the team is stored in our local computers and unavailable for other team members. I don't think adding those files to source control is the best approach, but the only other way I see is deploying to an external IIS for debugging.
Have you already worked with this scenario? Wwhat do you think is the best option? Thanks in advance
thus new content (aspx pages) created by each member of the team is stored in our local computers and unavailable for other team members ... I don't think adding those files to source control is the best approach
I really wonder why you think that is a bad idea... I think adding created code in your source control system is the very best thing to do.
What do you think happens if a computer stops working, gets stolen, etc? How do you obtain the file again? Store every file that is crucial to your system in a source control system.
I guess you can have a "tools" folder in project structure where you keep all of your test pages. Then when project is built that folder can be excluded from copying.
For example when Release build is executed "tools" folder is excluded, while Debug builds leave it in the project.
It really depends how do you guys work, how many of you there are, how often do you do delivery cycle - but generally garbage of test pages tends to grow all over the place (same as commented out code) if there is no systematic approach and whole project team chips in.
I'm trying to setup our CI build environment and having an issue.
First, I'm using VS and TFS 2012 so I can't use the *.12.xaml templates since those are for VS/TFS 2013.
Second, right now I'm configured to use just the defaulttemplate.11.xaml. Originally, I was using WebDeploy for the deployment method and that was working great. Since then, our web/server team has re-configured our test environment to use IIS Shared Configuration as well as DFS Replication to keep everything in sync.
Because of that, I'm no longer able to use WebDeploy (I passed this post over to the TFS admins, but they said no).
Is there a place where I can add some msbuild arguments, or a post-build event where I can send a *.cmd file with some arguments so I can get my code copied/deployed?
I've read Hanselman's (and everyone else that copied him) posts/blogs that say "if you're using xcopy, you're doing it wrong, etc...", but I believe in my case I CAN'T use Web Deploy.
Update:
So I thought I found my answer. Since the web deploy doesn't work for me, I found a workflow activity called CopyDirectory that sounded exactly like what I need.
I went through the process of updating my default template to add this additional step to the build process, which by the way, does NOT work very well. After adding the step, saving, etc, the step doesn't ever show up in my build output. I gave up for awhile to go see if I could do this on our Jenkins build server, got some different errors over there so I came back to TFS to make the changes and commit. Since the CI was still setup in TFS (granted, failing), I noticed that a build got kicked off when I made my commit. I decided to watch for awhile and IT FINISHED SUCCESSFULLY! Woah, all right. So I checked through the build logs, and find out that it threw a WARNING saying "failed to copy. Ensure the source directory exists and that you have the appropriate permissions".
Well, since I just entered this value incorrectly, no big deal, just change to the correct BuildDetail.DropLocation, and we should be golden.
WRONG, after building again with my changes to the source and destination values, I come to find out that since I'm trying to deploy my files to a different domain, it still fails.
Oh, and in addition to that, YOU CAN'T PASS CREDENTIALS TO THE COPYDIRECTORY STEP! REALLY! Phew, I found some documentation though, it says "give the tfs build service/account permissions on the domain that you want to copy to. Well, that would be great, if my server team would allow that, but they don't.
Back to square one...(this is going to turn into a blog about me complaining about TFS...)
I believe you can do it using robocopy. You will want to update your build template to include a new InvokeProcess activity. Set the activity's FileName to "RoboCopy" (include the quotes) and it's Arguments to something like the following:
String.Format(" ""{0}"" ""{1}"" /E /R:10 /W:10 /NFL /NDL ", BinariesDirectory, BuildDetail.DropLocation)
Of course changing the robocopy flags to your specific needs.
I don't think you can pass credentials into robocopy either though, so you might still be SOL there.
One possible alternative though is that because your admins won't give the TFS Build User (i.e. tfsservice) permissions on the destination box, you could change the TFS Builds to run as a different User that does have permissions on that box. To do this I believe you just have to log onto your TFS Build machine, go to the Services, find the Visual Studio Team Foundation Build Service Host 2012 (or something similar), and change the Log On As user from tfsservice to whatever user has permissions on the box that you want to publish to. Of course you will also need to give that user permissions to do everything else that the build system needs to do (download source code, etc.).
I have a WPF project set up to use a local SQL Server Compact database through an ADO.NET Entity Data Model in Visual Studio Express 2012 for Desktop. The project works great, on first run I can load all of the data, manipulate it as I please and come back later with the changed data still in place.
I noticed while doing a little restructuring to the schema that the data visible to VS was only the very first bits of data that I entered manually when creating the database and the next time I compiled all of the data I had added since was gone!
After some digging, I came to the conclusion that the compiled version of the app was using the SDF file sent to the bin/Debug folder by the file's Content:Copy If Newer build action. This means that there could be as many as 4 different copies of the database to be worried about: project folder, debug folder, release folder, and the deployed copy on the end user's PC.
I would like to have a single copy of the database on my dev machine that is accessed by both debug and release compiled versions and the database explorer in VS that is installed on the end user's PC by ClickOnce. I suppose I could change the connection string to an absolute path during development and hope I can remember to change it back to relative before I publish for deployment.
Finally, I foresee the need to release updates for this application as well and am worried that such an update would erase the end user's data if improperly done. If possible, I would like to be able to only update the schema of the end user's database without touching the data itself whenever I release an update. If this is not possible that is acceptable and I'll just have to make sure I put every structure I can think of into the database before my first deploy.
In summary my questions are the following:
How to share a single sql compact database between VS, debug, and release?
How to handle local database during application deployment and updates, with the optional ability to update the database schema without erasing the data?
I have a similar application and I keep the database file completely separate. Because you may also need to do updates that you don't want the user database overwritten. I have a process that checks the database schema before the EF connection takes place. So when my users install this application it requires they download the database file from my webserver and puts it in a specific location on their computer.
For a new MVC web development project, I'm collaborating with a couple of other developers and we want to use Visual SVN to manage source control.
Following the "Getting Started" instructions at the VisualSVN website (http://www.visualsvn.com/visualsvn/getting-started/) seems to to commit everything within the Solution folder including all the settings file (.suo, user, .Publish.Xml)
However, we want to maintain separate Publish Settings within Visual Studio as we publish to our local machines for testing.
Is that possible?
P.S. Shouldn't VisualSVN Client automatically ignore the .suo and .user files?
it doesn't you'll need to either
add them to the ignore on commit lists - you can do this while committing but its a per user setting
remove them from svn - delete them from svn using tortoise as visual svn cant see them (take copies first, as I think this will actually delete them), commit the delete. Put them back into the folder and commit again, svn will show up these files as uncommited, right click on them and select ignore in the commit window, and commit them, this will apply to everyone. Its easier to not commit them in the first place :)
I use SVN as my source control as well. I also use VisualSVN (but only server side). The main thing I would suggest is to use VisualSVN to host your repositories, but use something else to commit/update/checkout your repositories to your local machine.
I would suggest TortoiseSVN for this. Use TortoiseSVN to control your workflow on local machines. You can then use it to simply right-click/ignore your *.suo files. Or any other files/folders you wish to keep out of the repository!
It may take a bit of research to get it setup. But this is what I use on an every day basis, and it is very user friendly.
I've never used VisualSVN, but I would be surprised...no shocked if what you said was true.
Does VisualSVN really by default automatically add and commit user files? You'd think a solution that's built for VisualStudio would simply know better. I would call the company and verify this.
If VisualStudio does commit local user files, I would recommend that you use AnkhSVN instead.
Not only does AnkhSVN know better than to commit user files, it's also open source and you can save yourself the $49 per user you need for VisualSVN. And, it's not just the $50 you're paying per user that you pay with VisualSVN either. It's also the fact that you have another license you need to track while users come in and leave the project. Who do you think is going to get that fun job?
However, if you must use VisualSVN, and VisualSVN does commit user local files by default, You need to get my kitchen sink pre-commit hook. One of the things it does is allow you to completely ban the addition of files such as Visual Studio's *.csuser` files and the other types of VisualStudio detritus.
Of course, you should let developers know how they can set global-ignores and autoproperties in Subversion. This will prevent them from accidentally adding them. But, there's no way you can configure that globally, or to prevent someone from purposefully adding them. Only my pre-commit hook can keep them out of your repository. After a few failed commits because your developers tried to add in these private user files, your developers will quickly fall into line and set up their global-ignores.