I have a very large website which was "published" using Visual Studio 2008 to the dev/live server. As a result, there are no *.aspx.cs files on the live server, just "website.dll" - all good so far.
However, because we're constantly having to add pages to the site this now means that if I'm half way through developing a big part of the site when I'm required to make a small change elsewhere, I can't publish "website.dll" to the live site because it has all my half finished code in there. How do people deal with this situation?
If I could split the site up into multiple dlls (perhaps based on namespace?) then I could just publish the small part of the site that's changed, leaving the bit I'm still developing on the dev server.
Thanks,
B
Your problem is not the single assembly, but your way of developing.
To cope with this problem I would introduce a source control system (svn, git, ...) in your environment. These allow you to use branches, you could create 2 branches. One for new development and one for bugfixes or small changes.
These can later be merged to create a new release.
More info can be found here or here and in the manuals of Subversion, Git and other source control systems.
No, you can't.
Split your project in several sub-projects and handle them in a solution. Every project will become a seperate DLL.
Use source control. We use subversion with ahnk+tortoise.
subversion on wikip
Related
I have an existing Umbraco-project running on an IIS-server. When I started the project I basically installed Umbraco directly to the server and coded through the Admin-interface until the site was launched and went live.
Now, the customer wants some changes and it feels like I've painted myself into a corner here, since I obviously can't make changes in the code while the site is running. So, my question, which I hope this excellent community can help me out with:
How do I proceed when I get a copy of the project locally, to develop in Visual Studio and then publish it back to the live server? Should I create a GIT-repo, or is WebDeploy an option? Which workflow is the most convenient when developing and maintaining an Umbraco site?
I am also quite insecure about what configurations are needed on the IIS-server to support deployment from my local machine, so some input about that would be much appreciated!
Don't tell anyone, but for file updates only (like stylesheets or templates), I sometimes just FTP them up or publish to file system and copy/paste the files via RDP. If you make changes to document types etc., consider if you can't just test them locally and recreate the changes in the live environment afterwards.
Of course, this is only viable for small changes/solutions and one-man teams, but I feel that it's perfectly okay since the alternative(s) get very complex very quickly.
Edit: and also it requires you to keep your local copy pretty close to the live one, so you can be relatively sure stuff doesn't break when you "publish".
You'll have to get a copy of the files from the server, but also use a local copy of the database and update the connection string in web.config to point to that, otherwise any backoffice changes you make will be made on the live server.
If you are just making changes to views then some kind of publish from visual studio will probably work, but if you are making new document types, macros etc., this also involves data changes in the database which won't be published from visual studio at the same time.
There are various tools out there which cater for this situation of making development changes and moving them to live.
The obvious one is that you repeat all the changes you made in dev on the live server, although this can become tedious if there are lots of changes.
There are also things like Umbraco Courier and another one which I can't remember the name of for the life of me that copy all the relevant things from dev to live in one go.
I'm trying to get one of our internal c# click once applications into VSOnline for source control to allow access for an external developer.
I think I've got it set up and working in the Source Control Editor, but am having trouble working through how to actually use the setup day to day.
I've got some git experience but zero TFS experience, but went with the TFS option as I thought it's more likely developers are familiar with it than git.
What I'm trying to achieve is 3 branches; Main/Trunk, Dev and Release and be able to deploy at least Release and Main. Release is for external clients, Main for internal clients.
At the moment my Source Control Explorer looks like;
DefaultCollection
-->Name of project
---->(Branch icon) Dev (created as a Branch from Main)
---->(Branch icon) Main
---->(Branch icon) Release (created as a Branch from Main)
2 things;
In terms of use I'm not really sure how to swap between the branches for coding / making changes? Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way? I'm worried about someone committing the wrong file and causing a mandatory uninstall/reinstall of the app.
Any pointers / docco greatly appreciated; just note I'm using VS2010.
Thanks,
Liam
How do I swap between branches
If you're used to GIT than the 'heavy weight' branching in TFVC can be a bit confusing. There is no real "Switching between branches" as you've encountered. You map a branch to a local folder and by opening the files there you're "working on that branch".
As Lee points out you can create separate workspaces for each branch, which will isolate the work areas for each. If you're using a Local Workspace, each workspace gets its own "/tf$" folder, the TFVC equivalent of the "/.git" folder.
There's a couple of documents on MSDN that explain this in a little more detail:
Set up TFVC
Create one or more workspaces
Optimize your workspaces
How do I check in
A changeset in TFVC is the equivalent of a commit in Git, it's a logical set of changed files that is committed/pushed as a whole, or not at all. But just as in Git, you can commit all the changes to your local work area at once, or you can exclude certain changes from the first commit and stick those in a second.
In TFVC you'd normally try to commit a logical set of files that fixed the bug, achieved some goal etc. Though it's still possible to check-out/check-in files individually, chances are much higher that you'll actually cause the sources in the main repository to be in an inconsistent state that way.
See
What is a Changeset
Check in your work
Shelving your work
As for your second question
Depending on how far you'd want to go, you could setup Team Build to actually build the application and to take the configuration from a specific location during the build process. That way you wouldn't have to store the configuration for your production environment with the development settings. Configuration files can contain sensitive information, you might not want to have them in Source Control, except for the development versions.
You can also store the config files in a special folder in each branch and make sure that each time you merge them, they're updated accordingly.
And you can, as Lee mentions, look into Config Transaformations. which apply some XSLT to your config file in the build process. That way you can have multiple config files stored in each branch and the selection of your "Configuration" in Visual Studio will define what the final config looks like.
See:
Tricks with app.config files and click once
The _PublishedApplication Nuget package
SlowCheetah
In terms of use I'm not really sure how to swap between the branches for coding / making changes?
I recommend creating separate workspaces for each branch. This way you won't accidentally check in release code when you are trying to check in dev code. Also, when you want to switch which branch of code you are working on, you switch your workspace. This should keep things "cleaner" and easier to work with.
Do I just open the solution file for the branch I want to work on then save all changes as I go, then commit that as a changeset? Or is it a matter of manually checking the file out, working on it, then checking it back in again?
You shouldn't have to manually check it out. If I remember correctly, it will default to auto check out when you start to make changes. You can check code in however big of chunks as you want. But make sure if you are checking in changes to ClassA.cs that reference needed changes in ClassB.cs, you check that in as well. You don't want to leave the source code in a broken state for the other developers.
If you start working on something and have to suspend that work to do some other task that rose in importance, shelve your work instead of letting your workspace get cluttered up with half done work that makes it difficult to manage check ins.
Given it's a ClickOnce app; each branch is deployed to a different IIS site, meaning diff app identies, paths and settings. Am I right in using branches for this or is there a better way?
I'd look into using web.config transformations for this. You'll still want multiple branches but to separate tested/completed/developing code from each other.
Hello I recently deleted what I thought was an unused folder which happened to have the solution and code for a windows application I am maintaining.
I have published the app multiple times with ClickOnce and have access to the application manifest, deploy, etc. Is there a way for me to use the published application to get back my solution?
Thanks
If you don't currently use source control, I would highly recommend using one. I'm not aware of a way to get back all the solution files without source control, but you can get back the code using .NET Reflector. There is a file disassembler add-in which allows you to dump the code straight out of Reflector.
not possible. you can't recover the solution and original code from the compiled and deployed version.
if you have not used that machine or hard drive since you deleted it, you may be able to recover the files but it's a long shot and may be expensive.
you need to invest some time in learning source control. git, mercurial, subversion... they're all free and easy to use in windows. having your code in source control would prevent this problem - delete it all you want, just do a checkout from source control again.
Just go get the project back from Subversion.
Basically all you can do at this point is feed the assemblies to a program like reflector and reverse engineer it back. Welcome to sucksville.
If you don't have your stuff in some type of repository already I'd highly recommend fixing that first thing in the morning. With free tools like subversion available, nevermind things like TFS or even VSS there just isnt a good excuse.
For a testing usage of not very complex WPF applications I often don't make installer - just, after building project, copy Bin>Debug folder content of a VS2008 project folder to a hard drive of a user computer and put an icon to a desktop. No records to windows registry.
Are there any drawbacks of such a way of using windows applications for testing period?
There's nothing wrong with this approach at all - it is what's called xcopy deployment. You don't get a few things doing it this way:
an entry in the add/remove programs for users to uninstall with
the ability to add shortcuts to desktop/start menu/quick launch
any changes to the registry for settings etc...
Another benefit is that you can get your application onto a computer by a user who does not need administrative privileges to install.
It really comes down to your requirements. If you don't need any features of an installer, then just copying the files is a good approach.
I'd agree with the other comments about using a release build though - especially if you are deploying for real use and not just testing.
The only change you might want to make is to build the app in Release rather than Debug and take the files from the Bin>Release folder.
more info: http://haacked.com/archive/2004/02/14/difference-between-debug-vs-release-build.aspx
When you have multiple files to deploy along with your exe, dll's to register, file associations to set up, then an installer is a neat way to deliver all of that in a reliable manner. If you don't do this with an installer the user could easily screw things up.
In addition to that, the installer is sometimes used as a means to ensure the computer is truly ready for the application. For example, the installers I've written check to ensure the proper version of .NET is installed, and will download & install it if necessary.
However, there are many times when these characteristics are simply not worth it and deploying a standalone application in a single exe is perfectly acceptable. Simple applications that don't need to store a lot of settings on your computer and don't have a lot of prerequisites are perfect examples. The first thing that comes to mind are all the utilities from Sysinternals.
I see only one potencial drawback. There is nowthing wrong in your approach as long as you don't have more than 1 to 3 users and changes during test session are not often.
When changes are often and you have to copy library to more than 3 users (hosts etc.) the drawbac I mean is maintenance time. I know what I'm talking about because in place where I work, we have such issue.
Last time I've started to more taking care about maintaining our application and copying files from one host to another than coding. :(
In my honest opinion sometimes is better to invest your time on the beggining and write an installer than have a lot mainteneance and copy things later.
To solve the number of users problem, there's a very simple solution that does not require to setup a full installer.
Basic setup for multi-users xcopy/.bat deployment:
A shared drive, with one folder for the .bat files, one for the binaries.
Upload the binaries to the shared
drive and update the install script
if needed.
Have every user run the install script.
By the way, some very complex information systems are ENTIRELY deployed by .bat files (even when not testing!).
I need to create a patching routine for my application,
it's really small but I need to update it daily or weekly
how does the xdelta and the others work?
i've read around about those but I didn't understand much of it
the user shouldn't be prompted at all
Ok this post got flagged on meta for the answers given, so I'm going to weigh in on this.
xdelta is a binary difference program that, rather than providing you with a full image, only gives you what has changed and where. An example of a text diff will have + and - signs before lines of text showing you that these have been added or removed in the new version.
There are two ways to update a binary image: replace it using your own program or replace it using some form of package management. For example, Linux Systems use rpm etc to push out updates to packages. In a windows environment your options are limited by what is installed if you're not on a corporate network. If you are, try WSUS and MSI packaging. That'll give you an easier life, or ClickOnce as someone has mentioned.
If you're not however, you will need to bear in mind the following:
You need to be an administrator to update anything in certain folders as others have said. I would strongly encourage you to accept this behaviour.
If the user is an administrator, you can offer to check for updates. Then, you can do one of two things. You can download a whole new version of your application and write it over the image on the hard disk (i.e. the file - remember images are loaded into memory so you can re-write your own program file). You then need to tell the user the update has succeeded and reload the program as the new image will be different.
Or, you can apply a diff if bandwidth is a concern. Probably not in your case but you will need to know from the client program the two versions to diff between so that the update server gives you the correct patch. Otherwise, the diff might not succeed.
I don't think for your purposes xdelta is going to give you much gain anyway. Just replace the entire image.
Edit if the user must not be prompted at all, just reload the app. However, I would strongly encourage informing the user you are talking on their network and ask permission to do so / enable a manual update mode, otherwise people like me will block it.
What kind of application is this ? Perhaps you could use clickonce to deploy your application. Clickonce very easily allows you to push updates to your users.
The short story is, Clickonce creates an installation that allows your users to install the application from a web server or a file share, you enable automatic updates, and whenever you place a new version of the app on the server the app will automatically(or ask the user wether to) update the app. The clickonce framework takes care of the rest - fetching the update , figure out which files have changed and need to be downloaded again and performs the update. You can also check/perform the update programatically.
That said, clickonce leaves you with little control over the actual installation procedure, and you have nowhere close to the freedom of building your own .msi.
I wouldn't go with a patching solution, since it really complicates things when you have a lot of revisions. How will the patching solution handle different versions asking to be updated? What if user A is 10 revisions behind the current revision? Or 100 revisions, etc? It would probably be best to just download the latest exe(s) and dll(s) and replace them.
That said, I think this SO question on silent updates might help you.
There is a solution for efficient patching - it works on all platforms and can run in completely silent mode, without the user noticing anything. On .NET, it provides seamless integration of the update process using a custom UserControl declaratively bound to events from your own UI.
It's called wyUpdate.
While the updating client (wyUpdate) is open source, a paid for wybuild tool is used to build and publish the patches.
Depending on the size of your application, you'd probably have it split up into several dll's, an exe, and other files.
What you could do is have the main program check for updates. If updates are available, the main program would close and the update program would take over - updating old files, creating new ones, and deleting current files as specified by the instructions sent along with a patch file (probably a compressed format such as .zip) downloaded by the updater.
If your application is small (say, a single exe) it would suffice to simply have the updater replace that one exe.
Edit:
Another way to do this would be to (upon compilation of the new exe), compare the new one to the old one, and just send the differences over to the updater. It would then make the appropriate adjustments.
You can make your function reside in a separate DLL. So you can just replace the DLL instead of patching the whole program. (Assuming Windows as the target platform for a C# program.)