In the near future, I will be adding some features to my WP7 app. As seen here, I will be making some changes to the database. Where and how would you handle updates like this in the code? I don't think there is a way to add code anywhere than runs on an 'update'. It's hardwired into the apps code.
I'm thinking of having a flag that gets set in IsolatedStorage. Name it something like v1.2UpgradeFlag, and set it to false. In the App.xaml.cs, check that flag, and if it is false, meaning the upgrade hasn't run, run some set of code, and update the flag.
The idea of having code sitting there like that, that may not be applicable to multiple versions ago kind of clunky.
Edit: I'm also curious how I would manage cumulative updates to the application. So in v1.2, I have some code that updates the database schema. What if someone buys the app while it is at v1.3? I don't want them 'getting' v1.1, having the app run 1.2 upgrade code, to get to v1.3.
Since this is the first time you will have to run a database upgrade, I would be tempted to add an extra table to the schema that will hold the version information. If, when you attempt to retrieve the data, it gives a NotFound error, you know you will need to run the upgrade. That way, you can manage the process in subsequent versions without having to manage the extra file.
In order to do cumulative updates, you can use the same mechanism. You can maintain a method that will update the database from v1 to v1.2, another method to go from 1.2 to 1.3, etc. The method that maintains the upgrade process may look something like this pseudocode...
var currentDbVersion = GetDbVersion();
while(currentDbVersion < currentCodeVersion)
{
switch(currentDbVersion)
{
case 1.2:
RunUpgradeFrom12to13();
break;
case 1.3:
RunUpgradeFrom12to13();
break;
default:
break;
}
currentDbVersion = GetDbVersion();
}
That should allow you to upgrade from any previous version to the current without maintaining several code paths (since a 1.0 to 1.2 upgrade will never change, and you should have a known start position for each cumulative step)
There may well be far more sensible ideas out there, but this is the first thing I thought of.
Related
I have a Windows service written in C# running on Windows 10 and 11 machines.
Now I want to add some auto update functionality.
On my research I found Omaha. I could see, that I need a server part for it. But where to obtain a server? Due to some requirements I need to host the update server by myself and not to buy it as a service.
Or is there something else I can use as auto updater?
This is a really broad question and has no real definitive answer to it;
For any "Auto Update" action you would need a "server part" (as you call it) to host your new update. That could be anything really, even a GitHub page would suffice, but not a recommended solution.
If I were in your shoes I'd host a Virtual Machine somewhere with a dedicated (sub-)domain attached to it, so you have full control, but that being said: read on...
You would need to host 2 items: "what version am I currently hosting" and "the version itself" (since you don't want to download a complete service each time you start-up). So the "version" part could just be a simple JSON with a version number, if the current version doesn't match the new number, you might want to download the update and update the application.
But you also mention it's a service. This is not an easy task to auto-update. You can, of course, update the files in the folder where the service is installed (and by that I meant it in the broadest way possible: there is an option not all machines have the same folder) - and you cannot update a file which is "currently used" - which for services is actually almost always. So you'd first need to stop your service, update the files and restart after updating. With (also a bit of a task) the option to rollback if the changes fail (otherwise no service at all to start).
I would suggest not looking into Omaha since it's C based and not C# based (as you tagged your question), it would lead you into a world of hurt where you assume C and C# are alike (but far from the truth in most cases).
Besides the C and C# thing - Omaha acts like a Service on itself, which is a good thing, but most likely not what you're looking for - do you want the "second update service" to search for new versions every x time or do you want to control this flow (without user intervention).
I know this has raised more questions than it is an answer, but if I were you I'd reconsider the "what" "how" and "if" parts before I'd create an auto-update-thingy for "just 11 machines" (not to be condescending - not at all)
I'm working on a website which will be used all over the world and has to be highly disponible at anytime anywhere on the planet. That's why I try to use all the possible tricks to reduce at maximum the need of recompiling/restarting the website when minor maintenances must occur.
The ability in Asp.Net MVC to edit a view and have it automatically and dynamically recompiled by the framework without service interruption is really great and perfectly fits my needs. But its interest is strongly limited if I cannot edit the underlying model in a similar way and must recompile the whole stuff.
So my question : it is possible in any way (even an awful, hacky one) to define the view model class right inside the view itself in a code block ?
Otherwise, which trails could I explore to achieve a 'hot-editable' website (I mean : whose parts could be recompiled while the site is still alive, with changes taken into account straight away) ?
Thank you so much in advance ! :-)
If you are that concerned about performance and up time, consider using a server farm to host your site. When you need to make updates, you can take each server down separately so that your site is always available.
However, most deployments only take a few seconds. Your application may need more or less time to spin up (EF view generation may take 10-20 secs for example), but as long as you update during off peak hours you should be fine.
Also, I would NEVER EVER recommend changing code on a live server. You will break something eventually.
Eventually I managed to achieve the goal with another strategy.
All views have the same model called DataSource which globally is a recordset open before the rendering and closed after (if needed, reads are performed by the Razor code inside the view).
The column list of the recordset may change live without making the site crash.
For forms and validation, metadata taken from the database about the underlying stored procedure lead to a code emission which dynamically create a c# type, and that's it. Despite a new type is generated each time the sp is changed, the app pool recycling rate prevents too many obsolete types zombiing in memory.
I need to make some test changes on app. The app has version control (by Perforce). How to make a branch (from Perforce) that I don't intend on check back in so that I can do some test modification.
It depends on what you mean by not intending to check it back in. Do you mean never, or just not into the main branch?
If you really just want to make some local changes, and then throw them away, without needed any form of version control on the changes themselves, then you don't need to branch at all. Just sync up, check out what you're changing, and then revert the files afterwards. You can even re-sync the files while you're working (resolving conflicts) if you want to check your local changes in the later build. Just don't submit anything, and you're good (just remember that P4 has no backup of your local changes, so if your PC dies and you didn't back it up, tough).
If you want to be able to switch between your local changes and your normal build, you could 'shelve' your changes, which essentially submits them into P4, but keeps them in a changelist rather than having them actually integrated into the main branch. That way you can revert back to the "real" version of the files, and re-sync your own changes again later - possibly even on a different machine. This is a lightweight way of being able to make local changes, while still having a copy on the P4 server without polluting the depot.
If however you want a proper change-tracked branch of your own, you could integrate the version you want to base it on over into a fresh part of the depot, and then use a client-spec which syncs with that while working on it. You are free to integrate between your branches in either direction, whenever you want. You can branch either the whole tree, or just a sub-set of it, using client-specs to sort out which bits go where.
Alternatively the recent versions of P4 have "streams", which are an alterative way of handling your depot, more suited to running multiple development and release branches in parallel. It's probably not what you're looking for.
In terms of exactly how to do these things, I recommend checking out P4's website, which has pretty good documentation and lots of tutorials.
Actually you do not need to create new branch for test your change. Just make a client containing your app and sync your local computer. After that you need to change on specific files or add new or delete by shelve. Then just build your app with shelve. If you find your change at build artifact and if you think that your change is correct then you can submit it to perforce.
The easiest thing is to go to the "steams" tab. Create a new stream and check the check box for branch from where you want to branch from. Super easy.
At my workplace we deploy internal application by only replacing assemblies that have changed (not my idea).
We can tell which assemblies we need to deploy by looking at if the source files that are compiled into the assemblies have changed. Most of the time we don't need to redeploy assemblies that depend on assemblies that have changed. However we have found some cases where even though no source files in an assembly have changed, we need to redeploy it.
So far we know that any of these changes in an assembly, will require all dependent assemblies to need to be recompiled and deployed:
Constant changes
Enum definition changes (order of values)
Return type of a function changes and caller uses var (sometimes)
Namespace of a class changes to another already referenced namespace.
Are there any other cases that we're missing? I'm also open to arguments why this entire approach is flawed (although it's been used for years).
Edit To be clear, we're always recompiling, but only deploying assemblies where the source files in them have changed.
So anything that breaks compilation will be picked up (method name changes, etc.), since they require changes in the calling code.
Here is another one:
Changes to optional parameter values.
The default values get directly compiled to the assembly using them (if not specified)
public void MyOptMethod(int optInt = 5) {}
Any calling code such as this:
theClass.MyOptMethod();
Will end up compiled to:
theClass.MyOptMethod(5);
If you change the method to:
public void MyOptMethod(int optInt = 10) {}
You will need to recompile all dependent assemblies if you want the new default to apply.
Additional changes that will require recompilation (thanks Polynomial):
Changes to generic type parameter constraints
Changes to method names (especially problematic when using reflection, as private methods may also be inspected)
Changes to exception handling (different exception type being thrown)
Changes to thread handling
Etc... etc... etc...
So - always recompile everything.
First off, we have sometimes deployed only a few assemblies in an application instead of the complete app. However, this is by no means the norm and has ONLY been done in our test environments when the developer had very recently (as in within the last few minutes) published the whole site and was just making a minor tweak. However, once the dev is satisfied they will go ahead and do a full recompile and republish.
The final push to testing is always based off a full recompile / deploy. The pushes to staging and ultimately production are based off of that full copy.
Besides repeatability, one reason is that you really can't be 100% positive that a human didn't miss something in the comparisons. Next, the amount of time to deploy 100 assemblies versus 5 is trivial and quite frankly not worth the amount of human time it takes to try and figure out what really changed.
Quite frankly, the list you have in combination with Oded's answer ought to be enough to convince others of the potential for failure. However, the very fact that you have already run into failures due to this lackadaisical approach should be enough of a warning flag to stop it from continuing.
At the end of the day, it really boils down to a question of professionalism. Standardization and repeatability of the process of moving code out of development, through the various hoops and ultimately into production are extremely important in creating robust mission critical applications. If your deployment process is frought with the potential for failure due to these types of risk inducing short cuts, it raises questions on the quality of the code being produced.
Firstly, I think this forum is not appropriate for my question, so if it is in wrong place, kindly forgive and place wherever appropriate. I didn't find proper forum for my question.
I have developed a C# application (Win Forms). Now I need to handle its version numbering. I can't make out what is the best way to do. I want the version number to be simple something like 1.2 or 1.2.1. I read about SVN Version, but that also seems little confusing at this stage. There are different version types for the application - 1 with the installer , and 1 without installer.
I think the release version and the development version should be the same - please correct me if I am wrong. Should it be handled automatically or change manually? What are the best, simple and easy way to handle version numbering of an application.
We use major.minor[.build[.revision]]. And we give the semantics of:
major = major version. (Kind of big changes, maybe even with UI refresh).
minor = as medium set of changes. (maybe new internal processes or engines' refactoring).
As for build and revision:
0 - Means its alpha stage.
1 - Beta.
2 - Release candidate.
3 - Production.
So, if your app its on 3.2.1.0. You know you're at the alpha stage of the 3.2 version. And so on.
NOTE: Although it may seems kinda large to include the revision we found it to be a good practice because if we found some bug or unexpected behavior we just fix and increment revision and not build.
I think - and this comes from my experience, not just an idea - that you should use 4 part version numbering - very much along the lines of #Randolf. However I would make a different definition of the parts and the versioning.
major - this should be incremented when the version is a new build, is not compatible with previous versions without an upgrade process, or when the build/development platform changes ( so moving from .net 2.0 to .net 4.0 would count.
minor - this should be incremented when the data structures underlying your application change ( whether this is a db or not ). This means that a data build or update will be needed, which for clients indicates the level of work that may be needed for an upgrade.
build - this should always be incremented whenever a full production build is made, as a release candidate.
revision - this should be updated for every build, and used for bug fixes on a release candidate.
This means that you can identify with the version number exactly which changes and fixes are in that release, which is crucial for support.
Manual or automatic - this route would imply a manual update, and this is important to enable you to identify what a release contains.
Release and development version numbers should generally be the same, becasue the version number should only be incremented when a build for potential release is made. Having said that, you should also make sure that you can do development on any supported version, which may be lower than current development version, if a new release is in testing.
Frustratingly, .Net seems to consider build numbers the 'wrong' way round, according to many people. AssemblyInfo specifies build number as [Major][Minor][Build][Revision], which to me doesn't make any sense. Surely a nightly build happens more often than a revision of the spec, and is therefore the 'smallest' change? I'm not going to fight against the framework though, so I'm just going to have to tolerate it.
Maybe it's the same root cause as the phenomenon of Americans specifying dates in the wrong order. Again, common sense would dictate large->small consistently.
With regards to organising this conceptually, I would say that each part of a four-part build number should indicate the most recent change of the appropriate magnitude; i.e:
Major: A major upgrade of the application, which you expect users to pay for if it's a commercial project. Users should expect to face infrastructure concerns, such as service packs and new .Net versions;
Minor: A significant rollup of bug fixes and change requests that would fulfil the description of 'small feature'. Anything that should arguably have been in the program already can be rolled into a minor version;
Build: Personal choice, but for me this would be the unique build number. If you get your binaries from an integration server, this could run into the tens of thousands. Likely to be a nightly build, but could also be built on demand when the PM says 'go'. The build number should uniquely correspond to an event that kicked off a full production build on the integration server.
Revision: Should correspond to an amendment to the specification, at least conceptually. Would typically match an item in the changelog i.e. all incremental changes up to and including change request x.
In BuildMaster, we consider the #.#.#.# release number format to represent:
[major version].[minor version].[maintenance version].[build number]
Since mostly I would be regurgitating information from our blog, I'll just give you a link to the article written by a colleague of mine: http://blog.inedo.com/2011/03/15/release-numbering-best-practices/
When it comes to updating your release numbers, I would just leave the local development version at 0.0.0.0 and let your automated build process worry about the numbering.