visual studio Archives - Blog IT

git-askpass.exe: No such file or directory. Visual Studio

Ricardo Costa — Thu, 06 Sep 2018 12:57:44 +0000

I was getting an error when I tried to sync to my Git BitBucket repository with Visual Studio 2017:

git-askpass.exe: No such file or directory.

To resolve this I had to:

Remove Git from Control Panel -> Uninstall
Remove Git Windows Credential Manager from Control Panel -> Uninstall
With Visual Studio 2017 Installer, remove Git for Windows
Install Git
Install Git Windows Credential Manager
With Visual Studio 2017 Installer, install Git for Windows

The post git-askpass.exe: No such file or directory. Visual Studio appeared first on Blog IT.

How to add your custom content files into a nuget package (for Visual Studio)

Gustavo Brito — Fri, 12 Jan 2018 15:49:08 +0000

Yesterday, I was assigned to fix a nuget package solution that was not packing all the needed files. I had a bad time searching online for answers, and had to dig in by myself. After I discovered how to include the files that I needed, I decided to create a simple tutorial that has it all!

This tutorial will show you how to include your non-compilable items into a nuget package (nupkg). This steps apply to any type of file.

DISCLAIMER: You must have a nuspec file and a targets file. If you don’t have one yet, download one from somewhere and change the metadata accordingly.

Let’s start!

Open up your solution in Visual Studio
Open your solution’s nuspec file and look for tag
You need to reference all folders and all files that you want to include in your nuget. Example below:

    
    
    
    
 

4. After you added all files into nuspec config, now you can open your targets file. Don’t forget to import targets into your csproj file like the example below

5. Now to targets file, you must index ALL files that you want to add to your nuget. This step is very important



 
   
   Release
   bin\$(Configuration)\Package
   $(MSBuildProjectName).nuspec

6. After you added all your source files into your targets file, you are ready to pack it!!

File extensions for Transformations and generated classes:

A pp file extension is a class that’s generated when a nuget is installed in any solution. Usually, the class namespace is replaced by “$rootnamespace$” (without quotes) and the extension is added (yourclass.cs.pp)
A xdt file extension is a XML Transformation procedure.

Example of a *.pp class ready to be packed into a nuget:

namespace $rootnamespace$.App_Start
{
 using System;
 using System.Collections.Generic;
 using System.Configuration;
 using System.Linq;
...
}

That’s all folks!

The post How to add your custom content files into a nuget package (for Visual Studio) appeared first on Blog IT.

Remote resource handling in a MVC website project

André Santos — Fri, 15 Apr 2016 18:01:43 +0000

I don’t have very fond memories of using .Net resource files (.resx) to handle the translation of static web page elements such as form labels.

The Visual Studio resx editor was slow and using it to change resources that were more than a single line of text was a pain. I still have nightmares where I’m trying to edit complete email templates on a single field of a resx file…

The biggest problem with resource files, however, is that they are included in the project. This creates a problem for both the developers and the content managers, since the content managers are not able to change resources themselves, and the developers need to be changing resources files when they could be doing something productive.

The following will show a way to handle resource items in a MVC website project, where the resources can be stored wherever they are more easily handled by content managers: a SharePoint list, a database table, an excel file, or something completely different.

The process is really simple:

Select every resource item key needed to render the current page
Fetch the resources associated with the keys provided at the end of the current action
Populate a ViewModel property with the resource items
Use the resource items in their respective places in the markup

1 – Compile a list of resource keys

Typically in a website, there are certain areas of the layout that are common across all pages, the header and the footer being the most prominent candidates. There are, however, other areas that can be reused across a smaller subset of pages such as a common banner in the FAQ pages. Taking this into account, we split the resource keys by groups, where each group (a list of strings) contains every resource key needed for that area and load them on each action, like so:

model.ContentResourceKeys = new List<string>();
model.ContentResourceKeys.AddRange(ResourceHelper.SOCIALNETWORK_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.HOTEL_BANNER_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.DOCUMENTS_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.GENERAL_FOOTER_BANNERS_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.LANDING_PAGE_SEARCH_AREA_RESOURCE_KEYS);
model.ContentResourceKeys.AddRange(ResourceHelper.LANDING_PAGE_MODULES_RESOURCE_KEYS);

The ContentResourceKeys property is defined in a MasterModel that is extended by every View Model used across the site, as can be seen here: http://blogit.create.pt/andresantos/2014/11/07/pre-set-common-viewmodel-preperties-before-action-result/. That post also describes the Action Filter that is executed after every action on the site and it’s the place where we append the footer and header resources to the ContentResourceKeys list:

List<string> resourceKeys = new List<string>();
resourceKeys.AddRange(ResourceHelper.HEADER_RESOURCE_KEYS.ToList());
resourceKeys.AddRange(ResourceHelper.LOGIN_RESOURCE_KEYS.ToList());
resourceKeys.AddRange(ResourceHelper.FOOTER_RESOURCE_KEYS.ToList());
resourceKeys.AddRange(ResourceHelper.LOADING_RESOURCE_KEYS.ToList());
resourceKeys.AddRange(ResourceHelper.HEADER_COOKIES_RESOURCE_KEYS.ToList());

if (model.ContentResourceKeys != null && model.ContentResourceKeys.Count > 0)
{
    resourceKeys.AddRange(model.ContentResourceKeys);
}

2 – Fetch the resources

After compiling the resource keys needed, we go on and fetch the associated resource items. The project where this was implemented used a WebAPI to serve all the page content and the resource items were no exception. So, we send a POST request to the resource WebAPI method and fetch the needed resources, for the user language, from the available backoffice (we used a SharePoint list).

model.Resources.AddRange(ResourceFacade.ListResources(model.CurrentLanguageCode, resourceKeys));

3 – Add them to the View Model

The Resources property available in the View Model where we added the result of the call to the resources WebAPI method is a string Dictionary. Since C# Dictionaries don’t provide an AddRange method, we create an extension method that enables us to append resources to a dictionary that’s not empty. Moreover, with this extension method we are able to scrap duplicate keys:

public static class IDictionaryExtensions
{
    public static void AddRange<T, S>(this IDictionary<T, S> source, IDictionary<T, S> collection)
    {
        if (collection == null)
        {
            throw new ArgumentNullException("Collection is null");
        }

        foreach (var item in collection)
        {
            if (!source.ContainsKey(item.Key))
            {
                source.Add(item.Key, item.Value);
            }
        }
    }
}

4 – Use the resources in the views

Since every View Model extends the MasterModel, we are able to use the same property everywhere:

<footer id="footer">
  <div class="container">
    <div class="newsletter">
      <h2>@Model.Resources["Footer.Newsletter.Title"]</h2>

This way, we are able to manage the resource keys in a SharePoint list, or any other backoffice solution.

The post Remote resource handling in a MVC website project appeared first on Blog IT.

Automatic generation of Umbraco packages with Grunt

André Santos — Mon, 07 Mar 2016 16:03:50 +0000

Manually creating Umbraco packages can be tiresome.

If you’re continuously building upon the same package, doing it manually is wasting time that can be more useful developing new features.

This problem presented itself to me when improving Approve It. In order to create the Umbraco package I need several things:

The main assembly
The new dashboard section html file
The App_Plugins folder which contains every angular controller and views, javascript frameworks and custom css
The Package Actions Contrib assembly and its respective actions that enable me to bundle some translations in the package

I decided to go with Grunt and the Grunt Umbraco Package task. A grunt file is a script that typically automates the process of executing some tasks. These scripts can be executed on top of NPM, a package manager for javscript that provides a command line tool to run its packages. To streamline even more the package creation, I installed a Visual Studio extension called NPM Scripts Task Runner, that detects the grunt file and provides a simples UI to handle its tasks.

Step 1 – Install NPM

With NPM installed we are able to execute a Grunt file.

Step 2 – Install NPM Scripts Task Runner

The Visual Studio extension:

NPM Scripts Task Runner Visual Studio extension

Step 3 – Create a Grunt file

And place it in your project:

module.exports = function (grunt) {

    // Setup
    var pkg = grunt.file.readJSON('package.json');
    var projectRoot = 'C:/path/to/project/ApproveIt/';
    var packageNamespace = "Create.Plugin";

    // Grunt Configuration
    grunt.initConfig({
        pkg: pkg,
        clean: {
            files: [
                'bld/App_Plugins',
                'bld/bin',
                'bld/Umbraco'
            ]
        },
        copy: {
            release: {
                files: [
                    {
                        expand: true,
                        cwd: projectRoot + 'bin/',
                        src: [
                            packageNamespace + '.' + pkg.name + '.dll',
                            'PackageActionsContrib.dll'
                        ],
                        dest: 'bld/bin/'
                    },
                    {
                        expand: true,
                        cwd: projectRoot + 'App_Plugins/',
                        src: ['**'],
                        dest: 'bld/App_Plugins/'
                    },
                    {
                        expand: true,
                        cwd: projectRoot + 'Dashboard/Views/dashboard/approveIt/',
                        src: ['approveItdashboardintro.html'],
                        dest: "bld/Umbraco/Views/dashboard/approveIt/"
                    }
                ]
            }
        },
        umbracoPackage: {
            release: {
                src: 'bld/',
                dest: 'bin/umbraco',
                options: {
                    name: pkg.name,
                    version: pkg.version,
                    url: pkg.url,
                    license: pkg.license.name,
                    licenseUrl: pkg.license.url,
                    author: pkg.author.name,
                    authorUrl: pkg.author.url,
                    readme: pkg.readme,
                    outputName: pkg.name + '.v' + pkg.version + '.zip',
                    manifest: 'package.xml'
                }
            }
        }
    });

    // Loading of Grunt Tasks
    grunt.loadNpmTasks('grunt-contrib-clean');
    grunt.loadNpmTasks('grunt-contrib-copy');
    grunt.loadNpmTasks('grunt-umbraco-package');
};

This file has three sections, which I’ll explain in a different order:

Setup
Grunt configuration
Loading of grunt tasks

Loading of Grunt Tasks

Most actions we need a grunt file to execute are simplified by the use of existing Grunt tasks. In my case, I only need 3:

grunt-contrib-clean: deletes files and folders
grunt-contrib-copy: copies files and folders
grunt-umbraco-package: generates an umbraco package

Grunt File Setup

Here I define a set of variables and load an external configuration file that contains project properties I use later on:

{
  "author": {
    "name": "André Santos",
    "url": "http://www.create.pt"
  },
  "devDependencies": {
    "grunt": "~0.4.5",
    "grunt-contrib-clean": "^0.6.0",
    "grunt-contrib-copy": "~0.4.1",
    "grunt-umbraco-package": "1.0.0"
  },
  "license": {
    "name": "MIT",
    "url": "http://opensource.org/licenses/MIT"
  },
  "name": "ApproveIt",
  "readme": "Umbraco Plugin that creates a section that shows all the content that is waiting approval for publishing.",
  "url": "https://our.umbraco.org/projects/backoffice-extensions/approve-it/",
  "version": "1.0.1"
}

Grunt Configuration

This section is where everything comes together. The package.json configuration file is loaded and the three aforementioned grunt tasks are implemented:

Clean

In here, the directories used as the source for the umbraco package creation, are configured so that when we can empty them at will

Copy

This task copies every file needed by the plugin to a centralized location, creating a snapshot of our plugin. We copy full directories and hand picked files as needed.

Umbraco Package

Finally, this task picks up every file we have copied and creates the final Umbraco package. It uses the configuration properties set in package.json and uses a custom package.xml file so that I can include my custom post umbraco package install actions (using Package Actions Contrib):



  
    
      <%= name %>
      <%= version %>
      <%= license %>
      <%= url %>
      
        3
        0
        0
      
    
    
      <%= author %>
      <%= authorUrl %>
    
    ]]>
  
  
  
  
  
  
  
  
  
  
    
      
        
          approveIt
        
        
          
            views/dashboard/approveIt/approveItdashboardintro.html
          
        
      
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
    
  
  
  	<% files.forEach(function(file) { %>
  	
      <%= file.guid %>
      <%= file.dir %>
      <%= file.name %>
    
	<% }); %>

This file uses the Grunt templating engine so that, not only can I include the Package Action Contrib custom actions, but also some custom variables, such as:

The mandatory list of files that is automatically updated when a new file is added to the project output
The package.json variables

That’s it! We can now create new versions of Approve It without having to go into the Umbraco backoffice and doing it manually every time we need a new package version.

You can find the complete source code in my GitHub: https://github.com/ViGiLnT/ApproveIt. You can download the Approve It package here: https://our.umbraco.org/projects/backoffice-extensions/approve-it/.

The post Automatic generation of Umbraco packages with Grunt appeared first on Blog IT.