When you write software, you often/sometimes divide your project into several subprojects. This mini series describes how to do this with Visual C++ 2010 (but this first part also applies to earlier versions). We start with creating a library project in form of a DLL.
Related articles:
When publishing to Windows Azure, you may get the warning WAT150:
warning WAT150: The project ‘MyProject’ is dependent on the following assembly: J:\Sources\MyProject\packages\Microsoft.Data.Services.Client.5.6.0\lib\net40\Microsoft.Data.Services.Client.dll. This assembly is not in the package. To make sure that the role starts, add this assembly as a reference to the project and set the Copy Local property to true.
This warnings means that one of your projects uses an assembly that’s installed locally on your computer (e.g. using ASP.NET in a worker role) but is not installed on the Azure instance you want to run the package on. So, usually you can’t ignore this warning as the resulting package won’t run.
The usual fix is to use Nuget packages instead of globally installed assemblies. However, if this doesn’t work (like in my example above where the package clearly comes from Nuget), there’s another culprit:
The Global Assembly Cache (GAC)
Basically, if the referenced assembly is registered in the GAC with exactly the same version, then Visual Studio will always use the assembly from the GAC. Because of this, the assembly won’t be copied to the output directory and thus won’t be in the Azure package – resulting in WAT150 warnings.
This seems to be like this by design. Quoting from MSDN:
If you deploy an application that contains a reference to a custom component that is registered in the GAC, the component will not be deployed with the application, regardless of the CopyLocal setting. In previous versions of Visual Studio, you could set the CopyLocal property on a reference to ensure that the assembly was deployed. Now, you must manually add the assembly to the \Bin folder. This puts all custom code under scrutiny, reducing the risk of publishing custom code with which you are not familiar.
This statements is not entirely correct. Setting CopyLocal to true works – but only for the project directly referencing the assembly. Unfortunately, CopyLocal is not transitive, i.e. if project A references assembly X.dll (registered in the GAC; with CopyLocal set to true) and project B references project A, then X.dll will only appear in the output directory of project A but not in the output directory of project B. (It would appear in the output directory of project B if X.dll wasn’t in the GAC.)
There are a couple of ways how to fix this problem, but they all are workarounds:
%WINDIR%\Microsoft.NET\assembly\GAC_MSIL and delete the assembly from here. Note though that these assemblies may still be need and some software may stop working.Nice error message, but could you please tell me which content files are missing/corrupted or how to fix this problem?
To fix this problem, I’ve attached the initial contents of the Help Viewer folder to this post.
HelpViewer21-VS2013.zip (Help Viewer 2.1; Visual Studio 2013)
Just extract to zip file to the local help store path. The path can be found in the registry (value name LocationPath):
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Help\v2.0\Catalogs\VisualStudio11 Visual Studio 2013: HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Help\v2.1\Catalogs\VisualStudio12
If you can’t find the registry keys here, try HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Help\... (i.e. without the Wow6432Node).
In my opinion, refactoring is the way to keep a software project clean. So, it’s good to have tools that support the refactoring process.
ReSharper is such a tool. It provides refactoring capabilities for C#/Visual Studio.
Unfortunately, the renaming code in ReSharper currently (version 7.1.1) contains a bug. This bug may prevent ReSharper from renaming all occurrences of a certain symbol.
The following code exhibits this problem:
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 |
using System; public class SomeOtherClass { public string GetString(int col) { return null; } } public class MyClass { public void YouCantRenameMe() { } public void ThisFunctionBreaksTheRenaming() { // The following line breaks the renaming. SomeFunction((row) => row.GetString(0)); } public void SomeFunction<T>(Func<SomeOtherClass, T> func) { YouCantRenameMe(); } } |
If you try to rename the method YouCantRenameMe() (in line 10), ReSharper won’t rename the method call in line 18.
The problem is the code in method ThisFunctionBreaksTheRenaming() which somehow breaks the renaming process.
Update: This bug is not present in version 7.1. So, for now, I’ve downgraded to this version.
If you have some binary files you need for your Visual Studio project but you don’t want to add them to your version control system, here’s a PowerShell script that does the downloading for you:
Basically this mimics a very simple dependency management.
Source Repository: https://bitbucket.org/mayastudios/powershell-downloader/
At the very top of the script, you define which files to download where.
For example, this downloads the x86 and the x64 version of a SQLite .dll file:
$base_url = 'https://mydomain.com/sqlite' $files = @{ '..\sqlite.dll' = "$base_url/x86/sqlite.dll" '..\sqlite_x64.dll' = "$base_url/x64/sqlite_x64.dll" }
Entries must be separated by line breaks or semicolon (;).
Paths are relative to the location of the script file.
To include the script in your project, call it from your project’s Pre-build event.
For example, if you’ve placed download.ps1 in a folder called libs in your project, use this line to execute it:
powershell -ExecutionPolicy ByPass -File "$(ProjectDir)\libs\download.ps1"
That’s it.
The script will download the files if:
a file named force-download.txt exists in the scripts folder and this file contains anything else but “false”
These rules are defined in the Needs-Downloading function.