Sorry, we found 0 results. Please try another query.
Showing max 10 of results

Proxy Switcher 3.6

Proxy Switcher version 3.6 has just been released.

Together with the new version, the new web site with its own domain has officially been launched. You can find Proxy Switcher from now on directly here:

http://proxyswitcher.net

The new version includes a new network detection method which has been requested by many users: Detect the network based on the MAC address of the gateway. Also a few fixes and performance improvements are included, especially the Ping feature did not always work as expected.
You can find the change log in the download section of the new site.

Neues Jahr, neue Blog Engine - Roadmap für 2012

Ich möchte dieses Jahr wieder mehr zu meinen Projekten schreiben. Ich habe da einige gute Ideen.

Das erste Projekt auf der Liste: Mein etwas angestaubtes Blog, basierend auf dasBlog durch eine neuere Engine ersetzen. Das habe ich nun gemacht und wenn du das hier liest, funktioniert BlogEngine.NET wohl. Das letzte dasBlog Release ist von 2009, wobei auf Codeplex weiter fleißig auch am Source gearbeitet wird. Dennoch habe ich mich entschieden zu wechseln. Das einzige was ich bisher vermisse ist die OpenId Integration. BlogEngine.NET hat da leider noch nichts. Zumindest konnte ich nichts finden.

Außerdem habe ich bei der Gelegenheit das Application Request Routing (ARR) Modul für den IIS installiert, damit die meisten alten Blog Links auch weiterhin funktionieren. Dazu habe ich einfach ein paar Redirect Rules erstellt. Somit funktionieren die alten Artikel Links auch weiterhin.

Eine weitere Neuigkeit ist: Proxy Switcher hat nun auch eine eigene URL (http://proxyswitcher.net). Das Ziel ist dort auch bald nicht nur einen Redirect zu haben, sondern eine eigene Seite.

NuGet Package Manager or How to make “source code sharing” across projects much better

Introduction

In a company with more than one development project sometime it happens that someone says: Hey, we need a common logging component shared across all projects.
Now the solution could be to develop such a logging component and share the assembly with all projects. However, if there is some code that should/must be unique to each project it is a bit more complicated. If you want to do that with SharePoint 2010 and build a logging component on top of the ULS log and want each project to be configurable in the Central Administration you need to know all future projects and categories or you need some unique code.

Note: The logging component is only a very easy example and might not be the best one.

NuGet

Microsoft created NuGet. A package manager for Visual Studio. Quote of the official site:

NuGet is a Visual Studio extension that makes it easy to install and update open source libraries and tools in Visual Studio.

You can add it easily to Visual Studio 2010 by Tools->Extension Manager. Search for “NuGet”. After it is installed, you can add packages to a project by right clicking on a project in the Solution Explorer and click “Add Library Package Reference…”

image

Now as a company you don’t want your super-fancy code to show up for everyone as open-source. Therefore, NuGet can have more than one package source. You can even use a file share. Open Tools->Library Package Manager->Package Manager Settings:

image image

Bring it together

To get rid of “each project copy the source from the source of the other project from the source of the source of the source from another project” you can now use NuGet.

The idea is:

  • Create the Logger.cs file
  • Add TODOs to the code where the developer need to change something
  • Make a NuGet package from it
  • Let the project teams use the NuGet package (and distribute updates to the source automatically as well!)

Advantage: There is only one source! And if the owner of the NuGet package updates it, all project teams will be automatically notified about an update!

Create the NuGet package

In my example I talk about the comon logger component. A single Logger.cs file. However, NuGet can handle even more complex packages with PowerShell code, etc.

So download the NuGet command-line tool and create a new folder where all the stuff for the package will go to.

Open a command prompt and enter:

nuget spec

This will automatically create an empty package specification file called Package.nuspec. Open this file in notepad and modify the required values. Also rename the file to match the id property.

image

Now create a folder called “content”. Everything in this folder will be merged into the solution on installation of the package. So I put the file Logger.cs in this folder.
However, I don’t want that all users are required to use the same namespace, so you can change the file extension to “.cs.pp” to let NuGet “pre-process” the file.

Within the file you can then set some tokens to be replaced on installation. You can find a list of available properties here on MSDN.

The folder structure looks like this:

image

And the Logger.cs.pp in the content folder:

image

As you can see, I used the token $rootnamespace$. That one will be replaced by the root namespace of the target project.

Ok, lets make a package:

nuget pack

The output is a file called SPLogger.1.0.nupkg. You can publish it to the official NuGet package server or use it only internally by copying it to a file share.
Now open Visual Studio add the file share as a package source and search for it in the “Add Library Package Reference” window or open the NuGet console in Visual Studio (View->Other Windows->Package Manager Console) and type:

Install-Package SPLogger

image

That’s it. If you change the version number in your .nuspec file, create a new package and copy it also to your file share, the project team can decide to update to the latest version in the “Library Package Reference” dialog. You can even uninstall the package and everything will be removed from the project without leaving anything behind.