Showing posts with label Visual Studio. Show all posts
Showing posts with label Visual Studio. Show all posts

Tuesday, December 29, 2015

How To: Run a Program in Administrator Mode

Often I need to run a program in administrator mode when using Windows. There are several ways to run a program in administrator mode on Windows 7. The way I've found to be the mode efficient is to pin it to the taskbar and set that pinned shortcut to always run as administrator. When you do this, it's a 2-click process - one click to launch it and another to accept the dialog.

Here's how to do that once you've pinned the program, this example is using Visual Studio 2015 since often it needs to run in admin mode to debug against local IIS.

Right-click any shortcut and click Properties. Here I am right-clicking the shortcut that is in the pinned program in the Taskbar. You can access these properties from any shortcut - on the desktop, or the start menu/screen to name a few.
In the Properties dialog, click Advanced*.
This dialog should appear and all you have to do is check the box and click "ok" and "ok" again and you are all set to run in admin every time.
*If you are right-clicking an icon for an exe you will find run as admin in the Compatibility tab of the Properties dialog.

Wednesday, July 2, 2014

NuGet HintPath Fix/Workaround

So we're using nuget and everything is awesome! We have a solution with projects that are maybe custom extensions or helpers that we will use in all our projects and life will be great! Now we bring those projects into another solution for part of this big project. We keep our concerns separated in separate solutions of course and share some projects that will help keep things cool and aligned. Then we build the solution and WHAT HO! What is this crazy nuget error? So we spend a bunch of time trying to resolve this (how many dev hours worldwide?) We find that the issue lay in the way nuget installs a ref to the packages folder in our projects. The path used is relative to the project. If we don't have them in the other solution's packages folder they don't exist and the build fails. You can resolve this in three ways:

Option 1: Edit the proj files to use $(SolutionDir)/packages/... well this doesn't work when the proj is built from msbuild directly without a solution. But it's pretty good.

Option 2: Build the dependent solution first.

Option 3: Add this to the proj file:
 <when condition="$(SolutionDir) == '' Or $(SolutionDir) == '*Undefined*'">
 <when condition="$(SolutionDir) != '' And $(SolutionDir) != '*Undefined*'">
replace '../' in nuget HintPaths:

Tuesday, July 1, 2014

Visual Studio 2013 project templates

.vstemplate is the extension.

While in the process of creating some boilerplate templates for solutions I learned quite a bit. The reason for creating these templates is that we have identified our best practices for using WCF services to wrap dbs and 3rd party APIs in services that we control. Other services related to business logic, workflow and logging have their own solution patterns that are pretty standard. I was searching for a way to automate new services via solution templates. I found that Microsoft surfaces the ability to create custom project templates for Visual Studio that can be used to do just that. There are a few caveats and I can't get everything I need to fully standardize the process without some manual steps or writing custom code, but it's a good start.

There are two basic styles of project templates to choose from - single project and multi project. There is no concept of a solution template. A multi-project template is what I was able to use to create solutions that contain a collection of projects. Here's how it works and some lessons learned that they don't tell you in the limited documentation.

A template collection is designed in a vstemplate file. This file references a vstemplate file for each project you want to include in the solution. The individual project templates point to the items to include in the project (proj file, classes, folders etc). These are single project files.

The documentation says to create a project and export it via VS File menu. This does some work to the proj file and creates the vstemplate. The collection of files is zipped up and put in the My Templates folder of the VS/Projects folder in Documents. If you selected the import option (checked by default) it also puts a copy in the ../Projects/templates folder that makes it available to VS when you create a new project.

The way I created the "solution template" was to create a subfolder in the Visual C# folder of ../templates for that solution type. I moved each proj zip into that. I unzipped the folder contents to their own folder. Then I deleted the zip folders. The multi-project vstemplate is at the solution template root under ../templates/Visual C#. The vstemplate refs each project template.

The good: We can now create projects with all the necessary projects included.

The bad: Haven't found a way to include solution level items in the resultant solution.

The Ugly: We use post-build scripts to set up the service locally in IIS when the configuration is set to Debug. The AppPool name is ProductServiceVx where Product should be only the product name. I thought I could use $safeprojectname$ which should be the user entered value in the new project dialog. This is not so in our situation.

So there are some manual steps for us. Here they are in a nutshell and how we are in the situation.

Create a new project in VS.

Pick a single name that represents the product - for EmployeeDataService, call it EmployeeData. All of the projects will be named using as the namespace and assembly name! Even the existing classes. In fact you can add $safeprojectnane$ in any files as long as you define replace as true on the element in the vstemplate.

But Wait! I want the proj names to be PeopleData.Interfaces, PeopleData.DTOs etc... They are, but then the classnanes become PeopleData.DTOs and my post build has PeopleData.DTOsVx as the AppPool name. Not what I want. Try as I might, I cannot find documentation on how to affect this declaratively. Hence the manual steps to crack open the projects and make adjustments. This opens up some risk of errors. Its palpable though since it takes so much work to set up a solution with 10 projects including dependencies.

Speaking of dependencies, enable NuGet package restore and bring in external dlls and projects that these depend on. But again, this is minimal compared to the overall time it takes to set up the solutions.

Speaking of time consuming, it did take a while to create the initial solution, then export each project and define the master vstemplate, but I hope it proves to be worthwhile in the end.