Friday, September 06, 2013
Monday, June 17, 2013
to avoid this just find the web.config in your views folder and locate the following section:
<host factoryType="System.Web.Mvc.MvcWebRazorHostFactory, System.Web.Mvc, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31BF3856AD364E35" />
<add namespace="System.Web.Mvc" />
<add namespace="System.Web.Mvc.Ajax" />
<add namespace="System.Web.Mvc.Html" />
<add namespace="System.Web.Routing" />
and add your custom namespace to it.
After you have done this reload your mvc project (or close Visual Studio and reopen it).
Tuesday, June 11, 2013
Windows Azure Logging not working Trace.TraceError throws: Not running in a hosted service or the Development Fabric.
<system.diagnostics> <trace> <listeners> <add type="Microsoft.WindowsAzure.Diagnostics.DiagnosticMonitorTraceListener, Microsoft.WindowsAzure.Diagnostics, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35" name="AzureDiagnostics"> <filter type="" /> </add> </listeners> </trace> </system.diagnostics>
After removing this: it created WAWSAppLogTable as expected.
More info can be found here: www.windowsazure.com
for local debugging I left the line untouched... I created a new config transformation where I added:
<system.diagnostics> <trace> <listeners> <add name="AzureDiagnostics" xdt:Locator="Match(name)" xdt:Transform="Remove" /> </listeners> </trace> </system.diagnostics>
Which is quite logic since Azure websites is not hosted in the AppFabrik
Friday, June 07, 2013
You can find the binaries in the packages folder in your solution directory
Wednesday, December 19, 2012
Saturday, July 28, 2012
Legacy systems are systems that have grown over the years and became harder and harder to change and or are build on outdated technologies. Since business is changing rapidly these systems no longer can keep up the pace. Certainly in people that sell services products that are sold can be very complex, take for instance insurances.
Often these systems are the core of the systems, if these systems go down you the company looses money, in certain areas you can loose thousands of dollars per minute you are down.
Signs that tell you that your current system will become unstable can be:
- More and more bugs, regression
- Implementing new features takes longer and longer
- Solving bugs takes longer
- Unable to scale up your system
- Upstaffing of your operational team
More about these symptoms you can read about here.
Usually when you start experiencing the negatives effects of these systems your legacy system will need to be changed quite urgently.
These symptoms will result into an increased TCO. Keeping the system operational will become increasingly difficult since people that operate these systems become older, skills required will become very rare.
There are several different approaches that can be taken to modernize your legacy system.
- Garbage in-garbage out: for certain languages there are tools that convert your source code from one language to another like vb6 to vb .net, vb .net to c#
- Big Bang Migration: full migration of a system, you rewrite your whole application at once ant one magic day you put everything at once in production.
- Incremental Migration: You partition your system in smaller subsystems and you put your system in production increment per increment.
Migration by tool
This approach can work if for instance you need to upgrade your system from one version to another. The biggest risk here is that when you do this you will not solve the fact that your software is difficult to adapt. It's an illusion that a system will be easier to adapt in a new technology than it was in the older one. What can be an added value of new technology is better development tools helping you with better support for refactoring to bring your system in a condition that is more suited to change and easier to change.
Big Bang Migration
This approach where you rewrite application from scratch and migrate your data from the old system to the new system. The biggest risk here is that when your project fails the entire project fails, the outcome becomes more unpredictable the bigger the project gets. The risk in this undertaking are generally huge and need to be assessed carefully.
This approach can be successful in projects that are quite small, your data is of high quality, you know your data structures and don't have a lot of dependencies on other systems.
There also is no guarantee that the new system you build will not start to show the same symptoms as your old one. If you do not put in place good programming techniques and adhere very strict quality guidelines the chance is big that the new system will become hard to change quite quickly.
Another downside is that business will not stop the evolve either you will be faced with the fact that you will need to implement old functionalities and in the mean time keep track of new developments also.
The cost is very high since you need to be operating your legacy system and in the meanwhile develop a new one which requires input from the people that are operating your legacy system which will have low availability due to the fact the need to keep the business afloat.
This approach is often chosen but often fails or costs enormous amounts of money.
When performing an incremental migration. You will have to divide your legacy system into smaller functional components and migrate each one step by step. The partitioning needs to be done just-in-time, enough to keep you busy.
The huge upside of this approach is that its the risks are highly controllable and that if something goes wrong the feedback is rapid and the impact of the failure is limited and predictable.
Another big advantage is also that you will be forced to build your system in such a way that is easily extended and changed.
The downside of this is that the people that operate your legacy system need to be actively involved with the new developments since they have indispensable knowledge about how the old system and the business operates, since they are responsible for operating the old system their availability might be quite limited. Combined with a significant increase in cost having to keep two teams.
It need to be taken in mind also that when doing an incremental modernization that every step you take needs to able to be rolled back so in the beginning this will require a significant effort to easily and rapidly deploy and rollback your changes.
Sunday, July 08, 2012
Some points to take into mind when using Git in combination with Visual Studio 2012, Resharper and NUGet.
Manually add following entries to your .gitignore file
################# ## Visual Studio ################# ## Ignore Visual Studio temporary files, build results, and ## files generated by popular Visual Studio add-ons. # User-specific files *.suo *.user *.sln.docstates # Build results [Dd]ebug/ [Rr]elease/ *_i.c *_p.c *.ilk *.meta *.obj *.pch *.pdb *.pgc *.pgd *.rsp *.sbr *.tlb *.tli *.tlh *.tmp *.vspscc .builds *.dotCover bin/ packages/ TestResults/ # Visual Studio profiler *.psess *.vsp # ReSharper is a .NET coding add-in _ReSharper* # Installshield output folder [Ee]xpress # DocProject is a documentation generator add-in DocProject/buildhelp/ DocProject/Help/*.HxT DocProject/Help/*.HxC DocProject/Help/*.hhc DocProject/Help/*.hhk DocProject/Help/*.hhp DocProject/Help/Html2 DocProject/Help/html # Click-Once directory publish # Others [Bb]in [Oo]bj sql TestResults *.Cache ClientBin stylecop.* ~$* *.dbmdl Generated_Code #added for RIA/Silverlight projects # Backup & report files from converting an old project file to a newer # Visual Studio version. Backup files are not needed, because we have git ;-) _UpgradeReport_Files/ Backup*/ UpgradeLog*.XML ############ ## Windows ############ # Windows image file caches Thumbs.db # Folder config file Desktop.ini ############# ## Python ############# *.py[co] # Packages *.egg *.egg-info dist build eggs parts bin var sdist develop-eggs .installed.cfg # Installer logs pip-log.txt # Unit test / coverage reports .coverage .tox #Translations *.mo #Mr Developer .mr.developer.cfg # Mac crap .DS_Store