Showing posts with label Package. Show all posts
Showing posts with label Package. Show all posts

Tuesday, August 4, 2015

Creating and Deploying Local Scala SBT Packages

In the last few months we have discussed various features of scala. Some features required using other scala packages. In this post, let’s discuss how we can create our own artifacts. We can also discuss how we can use these packages in other scala projects locally.

Let’s create a sample Scala SBT project AdderLib. It is using Scala version 2.11.7 and SBT version 0.13.8. Just select auto-import ...

Sunday, September 8, 2013

Resharper Extension - Auto Nuget Installation

In this post we are going to discuss a new Resharper extension. We are going to discuss why we need it and how it makes our lives easier as developers. The extension is called Nuget Support for Resharper. The package works like another feature of resharper where it suggests assembly references for types used in a project based on the other projects in a solution. The extension extends support for suggesting nuget package reference instead of an assembly reference if the assembly comes from a package. You can install the package using Resharper 8 EAP Extension Manager.



We discussed about Extension Manager feature in Resharper 8 EAP before. You can refresh your knowledge here.

Creating Package
Let's create a sample class library project Core.Interfaces. The project is targeting to framework version 4.5. You can skip this part if you already have a package to reference.



Let's add some interfaces to the project. This is a library for providing necessary API for order processing. Here we are providing an interface IOrder as a contract for an order. We are also adding an interface for Order Factory.


Let's first create the nuspec file for the project. We use Nuget command line tool to create the specification file. We need to provide the path of command line tool so that it could create nuspec for the *.csproj file in the current folder. To save the trouble each time, you can provide the tool's path in the %PATH% environment variable.



The specification is created with a few tokens. Let's cleanup the file keeping the required tokens as follows:


The tokens are populated with the assembly attributes as specified in AssemblyInfo.cs in the project if this nuspec is used to create the project. You can use the following mapping from nuget.org specification.



For our project, I have updated the contents of AssemblyInfo.cs as follows:


Now let's update the post-build event for the project to create a nuget package. Since we have nuspec file in the same directory as the csproj file, nuget tool should use nuspec file definition to create the package. It should then use the assembly for token replacement generating the resulting package. Here we are creating the package in a specific output directory. For the local development, we can use the path as a local repository for the package. Now updating the package in any project would use the latest source package.



Now whenever we build the project, the nuget package is created in the output directory. The package for Core.Interfaces is created as follows:



Adding Local Package Repository
Now let's make sure that the package is used from the local storage. We can also uncheck nuget.org path to make sure that packages from only this repository are being used. You might need to clear up local package cache for extra safety. Let's add the local package path to the nuget package manager setting as follows:



Using Package from Local Repository
Now let us add another class library project Core.OrderProcessing. We install the nuget package previously created to this project. Just make sure that Local Repository is selected before you install the package.



Let's provide the definition of the interfaces introduced in Core.Interfaces project as follows:


Now let's add another project to write unit tests for our library. Let's use xUnit for these tests.We discussed about this extension in our Resharper 8 features' discussion here.



Let's add the following tests for testing OrderFactory:


Since the types are returning interface types, we need to reference Core.Interfaces library. Here Resharper is really helpful for helping us what library references we are missing. It goes one step further by making it easier. It provides the support in action bar to add the required assembly, which is quite amazing.



Selecting the above option add the required assembly reference in the project. This is a well known resharper's feature. Although this is great for other assemblies but this is not perfect for the assemblies coming from a nuget package, which is exactly the case here. The assembly is referenced from packages folder.



Extension to Install the Source Package
In order to help us with the above scenario, we can use Nuget Support for Resharper. This is a resharper extension which can be installed using Resharper's Extension Manager. If we install this, then selecting the same extension would not directly reference the assembly from packages folder. It would install the source package instead. Installing the source package would automatically install the other dependencies for this package, which is even better.



It must be remembered that the extension doesn't add an extra item to the action bar. It just uses the option to add the assembly reference but it installs the source package, and hence, all of it dependencies. Since the type was sourced from Core.Interfaces, the same package is installed. An entry is added to project's packages.config file. The package installs a reference to the required assembly. Additionally all the required namespaces are added to the code.



Zindabad!!!

Possible Improvements
There is still room for improvement for the extension. Although it does a very good job for installing the source package in the scenario where the types are sourced from a package but it seems to only work in the scenario where there is an explicit usage of types. In the case of implicit scenario where the assembly should be referenced because of cases like return type of a method used. In those cases, still the resharper suggests to add the required assembly and the assembly is directly referenced from the packages folder. Let's update the code for our test as follow.


Here we are not explicitly specifying the type but since GetOrder returns an IOrder, it requires an assembly reference of Core.Interfaces.



Let's see the reduced options in the action bar. There is an option to add the required assembly reference. Let's use that.



Selecting the above does add the required assembly reference (resharper's feature) from packages folder. It doesn't install the required package. I think the extension can also listen for this scenario and install the source package instead.



Download

Tuesday, September 3, 2013

Project Retargeting Framework Version and Nuget Package Installation

Earlier we discussed an issue with portable class library references when a project is retargeted to a different framework version. The issue was discussed here. It was subsequently reported to Microsoft on Connect. The issue was that portable class libraries have restrictions when we add their reference to a target project. But if a project's target framework is updated after we have added a portable class library reference then we don't know what references of PCLs do we need to update. Later it was improved a little to provide visual cue for invalid PCL references.

Let's use the same NugetPackageRestoreEx console application created in the previous post. The project has Ninject nuget package referenced.



When the package was installed to the project, the project was targeting .net framework 4.5, hence all the required references were also targeting the same framework version. The world is really a happy place.


Now let us retarget the project to .net framework 3.5 from the property page of the project.



As we retarget the project, the nuget package references might become invalid. Nuget 2.7 added a new feature to help in this case. As soon as we retarget the project, there is a build error generated and the Errors List window is displayed with the details about the possible error.



The update has also added a new attribute to the packages.config schema. This is also notified in packages.config stating that you would require a re-installation of this package as per the updated targeted framework version of the project.



The error is transformed into a warning as we rebuild the project. Since the developer has been notified with the possible risk, it should be fine.



Download

Saturday, April 27, 2013

Nuget 2.5 Released This Week!

Microsoft finally released Nuget 2.5 this week (Apr 25, 2013). It is a very big release with 160 work items. In February, we discussed about some of the challenges introducing Nugets in an enterprise world. They included using nuget packages in an enterprise world and hosting internal nuget feeds. The release is a good news for native developers as the realase added support for C \ C++ projects. You can see the announcement on CoApp site where they announced CoApp power shell tools for Nuget 2.5. The tool was also released yesterday.



A new version of Nuget Package Explorer has also been released yesterday. The click once download is available here:



The new version of the explorer is released to be compatible with this release of Nuget [2.5]. There are still some features which are still not supported in the explorer including .net framework version specific references.



We can easily divide the released features as the improvements for packages clients and authors. There are various improvements for packages clients. The most obvious improvement which you would notice is the ability to update all packages which are already installed. Please notice the Update All button in the dialog to manage nuget packages.



As a package author, we can now enforce Nuget version on client machines before they install your package. This would make sure that clients have enough support for the features our packages are based on. Obviously this feature would be usable by the nuget clients 2.5 and above as the earlier clients don't know how to handle this metadata attribute. The attribute can be added as follows:

Installing Nuget package with requirement for higher version of Nuget would result in an error. In Visual Studio, it would show you the option to upgrade Nuget version. This would open the dialog for extension and updates in Visual Studio listing the available updates.



If you have earlier version of Nuget supporting previous versions of Nuspec, the package is shown in Manage Nuget Package dialog as follows:



The similar error message is available when package list is requested using Package Manager console (Get-Package -ListAvailable).



We cannot install such a package using Manage Nuget Pacakge Dialog.Installing such a package using Package Manager Console would also result in the following error message:



In the previous versions of Nuget, we could limit the assemblies to be added to target project's assembly references. The filtered list must be part of the assemblies in the lib folder or one of its framework specific sub-folder. Let's assume we had these two libraries in v4.5 folder for our package.



By default, if a client is adding this package, both of these assemblies would be referenced by the client project. If we need to reference only a filtered set of assemblies from the source set we can include the list in the nugetspec for the package. This would still copy all the assemblies to the packages folder.

This should allow you to include the assemblies that are dependent on some other assemblies where you don't want the types from these assemblies to be directly used by the client code.



Nuget 2.5 allows to define this filter based on the client's target project. This has been provided by including framework specific groups in the nuspec. We can also include a framework independent group as a fallback mechanism when our package is referenced by an unidentified framework version.


File Overwrite Option for Package Installation
A new option has been added for package installation to give the user an option to overwrite an existing file or keep the copy of the content already present. Please notice FileConflictAction with Install-Pacakge command. Here we are installing MyPackage while selecting to overwrite contents already present. The options are Overwrite and Ignore.



Installing package with Manage Nuget Packages dialog would give you an option to overwrite or ignore the content.

Import for MSBuild targets and props files
A new build folder is now supported at the root level in a package. The folder supports framework specific sub-folders. The build folder contains targets and props files. When a package is added to a target project, it would add <Import> in project file.



Please notice how these <Import> elements are added to the project definition. The element for build is added to the top of the project file.



The element for props file is added to the top of project definition as follows:



You can find further details about it from the release documentation available here:

http://docs.nuget.org/docs/release-notes/nuget-2.5

Sunday, January 13, 2013

.net framework 4.5 & Compression - ZipPackage and Open Package Specification API

In this post we are going to discuss how we can use the Open Package Specification API in .net framework for compression and decompression. Although we can not use the API to decompress the standard Zip files, but the compressed files using the API can be read and decompressed using the API. So if the feature under development needs decompression of self-compressed data files, the API can be used in a desktop application. It must be remembered that newer file formats including docx, pptx and nupkg are based on the Open Package Convention. Yes, it also includes Nuget packages. This is what msdn has to say about the System.IO.Packaging namespace.

"Provides classes that support storage of multiple data objects in a single container. ["msdn] The types for the API resides in System.IO.Packaging namespace in WindowsBase.dll assembly.


WindowsBase.dll is available as a default assembly in a WPF Application project, still we can add it manually for other project types.


The System.IO.Packaging namespace was added in .NET Framework 3.0. For dealing with compression and Decompression, we can use ZipPackage and ZipPackagePart types. ZipPackage inherits from the Package.


Similarly ZipPackagePart is the specialization of PackagePart type available in the same namespace.



Compression
Let's see how can we write a very simple code to compress packages using the packaging API. Below is a method that takes a folder name as input. It compresses the immediate files in a folder to the compressed file name provided as the second parameter to the method.


The above code gets the list of file names in a folder. It then creates a package and adds the files to the package as package parts. Please note that the sample code would just work for single level of files in a folder. We can use the similar code recursively to compress the folder hierarchy.

Here MimeMapping is from System.Web assembly and the same namespace. This is a new type introduced with .net framework 4.5. This type is not available by default with default Console application template and we need to add a separate reference of System.Web assembly in order to use this type. This type can be used to map document extensions to mime type.

Based on the Open package specification, the API creates a file [Content_Type].xml in the compressed file. The contents of the file is the details of extensions and their mime types. For my case, the contents were as follows:


This is the standard format for the file.

Decompression
Decompressing a compressed packages as also as easy. The caveat is that the standard zip files can not be directly decompressed using the API. This is because of the requirement of [Content_Type].xml file in the package to be decompressed. Actually Package.GetParts() wouldn't return anything if the file is absent.


The above code checks if the destination folder exists, it creates it if non-existent. It then reads the immediate contents of the package i.e. package parts and streams them individually to the specified folder.HttpUtility is also from System.Web. We have used UrlDcode from the type to remove any "%20" added to the file name. The method decodes them to spaces.

Download