onsdag den 12. november 2014
onsdag den 5. november 2014
Sitecore as a Nuget-package - Buildsetup Part 1
Issue
One of our main issues when developing Sitecore solutions is to keep our sites up to date with Sitecore files.The solution to this issue has for years been to run a custom robocopy script that copies the files from the public development server.
This requires that the server is always reachable, up to date and not infected with misplaced files.
Solution
I have made a script that takes a Sitecore zip installation file as input and creates a nuget-package from it.This article will show how this is done.
Following steps are taken when creating the nuget-package
- Initializing variables
- Unpacking zip-file
- Moving data-folder to App_Data/Sitecore
- Creating force.txt files to force empty directories to be included in nuget-package
- Copy developer license file to App_Data/Sitecore/License
- web.config changes - Correcting paths to dataFolder and license file
- Creating nuspec file - Syncronising version of Sitecore with the nuget-package
- Creating nuget package
tirsdag den 21. oktober 2014
Parameter "AssemblyFiles" has invalid value
Issue
When referencing an assembly the compiler fails with this error error MSB3248: Parameter "AssemblyFiles" has invalid value "C:\CruiseControl\...\myAssembly.dll". Culture is not supported. [C:\CruiseControl\Projects\TemplateSite\WebApp\WebApp.csproj]
error MSB3248: Parameter name: name [C:\CruiseControl\..\WebApp.csproj]
myAssembly is an invalid culture identifier. [C:\CruiseControl\..\WebApp.csproj]
Cause
This is caused by an invalid value in the AssemblyCulture attribute in the Assembly.cs [assembly: AssemblyCulture("myInvalidValue")]
Solution
Set the AssemblyCulture to a valid value e.g. en-US or da-DK or just set it to default [assembly: AssemblyCulture("")]
Etiketter:
asp.net,
Compiler,
culture,
language,
reference error
torsdag den 16. oktober 2014
How to prevent NAnt task returning code 3 to fail full buildprocess
Issue
The issue is that my buildscript fails because a task returns a code different from 0 even though the executable succeeds.The buildscript contains a task that copies my website to a development server.
I use RoboCopy.exe to do this.
The task looks like this
<target name="upload" depends="release">
<exec
program="${robocopy}"
commandline=".\Website ${devroot}\www ${robocopyUploadArgs}"
/>
</target>
However RoboCopy has a set of codes it can return depending on how many files were copied. See http://ss64.com/nt/robocopy-exit.html for more info.
Here it tells that a return value below 9 is a success.
Solution
By specifying to parameters; failonerror="false" and resultproperty="return.code" it is possible to tell NAnt that we dont want to fail on error but want the exit-code to be put in a property named return.code. Following a simple <if> task enables us to test and fail if the return code is larger than 8.The script now looks like this (remember to add property named return.code)
Etiketter:
CC,
failonerror,
NAnt,
property,
Task
torsdag den 18. september 2014
Sublayout caching disabled when sublayout is hidden by serverside code
Issue
I have a leftmenu that can be configured on the page-template to be hidden using a Sitecore field. When the editor sets a checkmark in the HideLeftMenu field the placeholder containing the sc:Sublayout control is hidden. This seems to result in that caching of the Sublayout is ignored.The code looks like this
Markup
<asp:PlaceHolder runat="server" ID="phLeftColumn">
<div class="col-sm-4 col-md-3">
<asp:ContentPlaceHolder runat="server" ID="cphPageContentLeft">
<dom:Sublayout runat="server" ID="submenu" Path="/layouts/LeftMenu.ascx" Cacheable="True" VaryByData="True" />
</asp:ContentPlaceHolder>
</div>
</asp:PlaceHolder>
Code behind
phLeftColumn.Visible = Sitecore.Context.Item["HideLeftMenu"] != "1";
lørdag den 23. august 2014
Automatic Multisite Handling By Traversing Sitecore Tree
Add automatic multisite handling to your Sitecore site by traversing the Sitecore Tree to find the available sites. You can decide to use the site name as subdomain or you can specify a hostName in a Sitecore field on the site-item.
lørdag den 18. december 2010
MVC 3
I have just installed VS 2010 and MVC3.
I like the idea that abstraction layers now is part of the programming interface and that it is now possible to test your website using unit testing. Hurra for that... But.. and I think there is a big but.
I have just created a new web application using the MVC 3 template.
This template creates a small site with login/logout/register functionality out of the box. Very nice.
But what I dont fancy at all is the fact that there is a lot of late bound code (Code that is resolved at Runtime).
Examples on late bound code:
1. ViewBag.Title (Set in Views and used in _layout)
2. @Html.Partial("_LogOnPartial") used in _layout
3. @Html.ActionLink("Register", "Register") (I know this is not likely to change name but what if it does and you forget to change it just one place?)
All these issues results in runtime errors but could in the "good" old days have been caught by the compiler by doing following..
1. Using Page.Title or a extension method on Page
2. Using @Register and tag
3. This is pretty much the same but would not resolve in a runtime error but a "not found" page. I dont know which one is better
Am I the only one with this concern?
I like the idea that abstraction layers now is part of the programming interface and that it is now possible to test your website using unit testing. Hurra for that... But.. and I think there is a big but.
I have just created a new web application using the MVC 3 template.
This template creates a small site with login/logout/register functionality out of the box. Very nice.
But what I dont fancy at all is the fact that there is a lot of late bound code (Code that is resolved at Runtime).
Examples on late bound code:
1. ViewBag.Title (Set in Views and used in _layout)
2. @Html.Partial("_LogOnPartial") used in _layout
3. @Html.ActionLink("Register", "Register") (I know this is not likely to change name but what if it does and you forget to change it just one place?)
All these issues results in runtime errors but could in the "good" old days have been caught by the compiler by doing following..
1. Using Page.Title or a extension method on Page
2. Using @Register and
3. This is pretty much the same but would not resolve in a runtime error but a "not found" page. I dont know which one is better
Am I the only one with this concern?
Abonner på:
Opslag (Atom)