A while ago I developed a custom TFS check-in policy that was working fine with Visual Studio 2015.
Now I installed Visual Studio 2017 and wanted to register the check-in policy assembly the same way as I did with VS2015 before. But this does not work. How can I register custom check-in policy assemblies with VS2017?
For VS2015, I had these registry keys:
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\14.0\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
and
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\14.0_Config\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
and accordingly I added those keys for VS2017 (15.0):
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
[HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\15.0_Config\TeamFoundation\SourceControl\Checkin Policies]
"MyCheckInPolicy"="C:\\Program Files\\My\\MyCheckInPolicy.dll"
But unfortunately this does not work:
If I open the Team Project SourceControl settings, go to the "Check-in Policy" tab and try to Add... a policy, MyCheckInPolicy does not appear1
If I open the team project that uses this check-in policy already and do the above, I got an error message telling me that the assembly (mycheckinpolicy) "has not been registered".
Of course I restarted the IDE after the registry change, but even rebooting my machine did not help.
The information I found so far seems to suggest that check-in policies now have to be part of an extension (vsix), which I don't want to believe.
I guess that the problem comes from some references that cannot be resolved when the assembly is loaded into the IDE.
The MyCheckInPolicy project references the Microsoft.TeamFoundation.VersionControl.Client.dll v14.0 from the VS2015 folder C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\CommonExtensions\Microsoft\TeamFoundation\Team Explorer.
I tried to reference the respective dll from the VS2017 folders, but then the assembly does not work in both IDEs.
I also tried to use the Nuget package "Microsoft.TeamFoundation.VersionControl.All" v12.0.30723.2 instead and deployed all files from the output directory (which seem to contain all assemblies of the package) to the location mentioned in the registry keys. This had the same result: the policy cannot be loaded in neither VS2015 nor VS2017.
We are using TFS 12.0.30723.0.
1So it seems VS2017 doesn't even try to load the assembly and does not care about the registry keys?
In Visual Studio 2017 there are breaking changes to extensibility. Much of the registry configuration has been moved into a "private" registry:
To reduce the impact on the registry, Visual Studio now uses the
RegLoadAppKey function to store registry keys in a private binary file
under %VsAppDataFolder%\privateregistry.bin. Only a very small number
of Visual Studio-specific keys remain in the system registry. (link)
By defining the registry keys as part of a .pkgdef file in a vsix, on installation VS 2017 will (I assume) write the keys to the private registry as opposed to the actual registry, which was the case in previous versions of VS. This will allow the policy to be picked up.
So, here are the steps I went through to get our policies working in VS 2017:
Install the Visual Studio SDK (can be done by modifying your installation if you didn't select the workload originally).
Add a new VSIX Project to your checkin policy solution
Add a .pkgdef file to the VSIX project with the following (this is the registry key entry):
[$RootKey$\TeamFoundation\SourceControl\Checkin Policies]
"YourPolicy"="$PackageFolder$\YourPolicy.dll"
Modify source.extension.vsixmanifest (using the GUI wizard) in the VSIX project:
Install Targets: Add your lowest supported VS Version:
Microsoft.VisualStudio.Community [15.0,16.0)
Microsoft.VisualStudio.IntegratedShell [15.0,16.0)
Assets:
Microsoft.VisualStudio.Assembly
A Project in current solution
Project: Select your checkin policy project
Microsoft.VisualStudio.VsPackage
File on filesystem
Path: Select your .pkgdef file from step 3.
Prerequisites: Visual Studio core editor [15.0,16.0)
Build the VSIX project and distribute/install the generated vsix
This GitHub repo was helpful for piecing everything together. Some quirks I found when migrating to the vsix:
By default, vsix installations are now per-user. If you operate VS under multiple users on the same machine you will need to install it for each. There is an option in the vsixmanifest to have the extension installed for all users, but this requires elevation.
Our checkin policy used an app.config file, which is not supported in a vsix. I had to migrate our settings to a .settings file.
It worked to me adding this key to HKCU:
HKEY_CURRENT_USER\SOFTWARE\Microsoft\VisualStudio\15.0\TeamFoundation\SourceControl\Checkin Policies
Hope it helps.
Thanks,
Wilsade
Related
I am building a webservice project on a TFS2017 Update 3 with build tools 2017. I get the following error
C:\Program Files (x86)\Microsoft Visual
Studio\2017\Enterprise\MSBuild\15.0\Bin\Microsoft.CSharp.CurrentVersion.targets(322,5):
Error MSB4019: The imported project "C:\Program Files (x86)\Microsoft
Visual
Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets"
was not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
What steps do I need to take to fix this error?
In my case, opening the existing Solution file (with .sln extension), it installed all the missing dependencies.
Otherwise check for missing target packages at nuget.org manually and install them (e.g. MSBuild.Microsoft.VisualStudio.Web.targets).
As per this GitHub issue, you'll need to set $(RoslynTargetsPath).
If MSBuild is installed on the machine and your tests run in a Visual Studio Developer Command Prompt, then you shouldn't need to do anything. However, MSBuild 15.0 no longer places itself in the registry which makes it impossible for MSBuild to find itself. This is because of a mandate by Visual Studio where you can have multiple side-by-side installations. MSBuild in this case would be installed once per Visual Studio instance. MSBuild now finds itself by looking at environment variables set by the VS command prompt.
If you want to fully redistribute MSBuild via a combination of our packages and all of the other packages needed to do full project evaluation, you will have to set RoslynTargetsPath before you load projects. You could argue this is an issue with NuGet since all packages' <contentFiles /> go to the the root of your output directory and you can't specify a subdirectory for certain packages.
If you're coming to this page from google/duckduckgo after trying to figure out why you're getting a similar message in Ubuntu 20.04, maybe this can help: https://askubuntu.com/a/1231973/1073658 (tl;dr apt install mono-roslyn from mono-project's repo)
First suggest you directly use msbuild command on the build agent with TFS build service account. This will narrow down if the issue is related to your agent environment or your TFS build definition.
According to your error info, the path C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\MSBuild\15.0\Bin\Roslyn\Microsoft.CSharp.Core.targets is looking the path of Visual Studio 2017.
However, for Build Tools the path is different should be C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Roslyn
Seems you haven't installed VS2017 on your build agent. This maybe the root cause of the issue.
The simplest solution is installing VS2017 on your build agent. Note, you need to reconfigure the build agent or restart build agent service to capture those new capabilities. Otherwise you need to change the corresponding import section in your .csproj project files.
I updated to TFS2018 and the problem got solved.
I have a VS2013 project for a Windows 8.1 Store App written in C#/XAML. I've configured a build using a TFS 2013 build template to build the solution for my project. There are a few other projects in the solution that are building fine (database project, web project, windows service project, WPF client app project).
When the Windows Store App builds I get the following error:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\AppxPackage\Microsoft.AppXPackage.Targets (1224): The "GenerateAppxPackageRecipe" task failed unexpectedly.
System.ArgumentNullException: Value cannot be null.
Parameter name: source
at System.Linq.Enumerable.ToDictionaryTSource,TKey,TElement
at Microsoft.Build.AppxPackage.DumpResourceIndexMap..ctor(ITaskItem[] indexedPayloadFiles)
at Microsoft.Build.AppxPackage.ResourceIndexMap.Create(String projectDir, String makePriExtensionPath, ITaskItem[] indexedPayloadFiles)
at Microsoft.Build.AppxPackage.GenerateAppxPackageRecipe.ExecuteImplementation()
at Microsoft.Build.AppxPackage.AppxPackagingTaskHelper.Execute()
at Microsoft.Build.AppxPackage.GenerateAppxPackageRecipe.Execute()
at Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at Microsoft.Build.BackEnd.TaskBuilder.<ExecuteInstantiatedTask>d__20.MoveNext()
I'm passing the following parameters to the MSBuild Arguments in the build configuration: /p:VisualStudioVersion=12.0 /tv:12.0. Also in the Package.appxmanifest settings under the "Packaging" tab I've set the Generate app bundle setting to Never. I'm not sure what other settings may be relevant here so please let me know if there are other details I can provide that would help you understand my situation better.
The project builds and packages fine on my development system. If I run the Project --> Store --> Create App Packages... wizard from within VS2013 it generates the .appx file.
I really don't know where to look next. Thanks for any help you can provide!
Steve
I took a fresh look at the problem today and have managed to end up with a functional build. The problem seems to be with our customized build template from TFS 2012. It turns out the Xaml activity for running MSBuild in TFS 2012 is named MSBuild and for TFS 2013 it is named RunMSBuild. The 2012 flavor of the activity explicitly runs the MSBuild.exe from the .NET Framework 4.0 installation typically found here: C:\Windows\Microsoft.NET\Framework\v4.0.30319. The 2013 flavor of the activity runs the MSBuild.exe from the TFS 2013 installation of MSBuild typically found here: C:\Program Files (x86)\MSBuild\12.0\Bin. In order to build Windows Store Apps for Win8.1 you must use MSBuild for 2013.
Our customized build template provided us with automatic assembly versioning in the scheme we prefer which is why I was using that template. It seems I will have to use the new TFS 2013 template (TfvcTemplate.12.xaml) as a basis for our updated custom template from here.
Hope this information might be useful to someone someday. Thanks!
I recently upgraded my n-tier solution from .NET 3.5 vs 2008 to 4.5 visual studio 2012. Every thing went fine apart from crystal reports and I had to install new runtime crystal reports for visual studio 2012 from the following link http://downloads.businessobjects.com/akdlm/cr4vs2010/CRforVS_13_0_5.exe.
After installing the above package I had to resolve some deprecated function and properties of
CrystalViewer and after that reports rendering properly in development environment (Windows 7 64 bit, SQL Server 2005, Visual Studio 2012). When I deployed the package in test environment windows server 2008 R2
the Application failed to load by throwing error
Could not load file or assembly Microsoft.ReportViewer.WebForms, Version=11
I managed to resolve ReportViewer.WebForms error by copying the DLL
from C:\Program Files (x86)\Microsoft Visual Studio 11.0\ReportViewer to bin folder of solution and set property copylocal = true and deployed the package. After that I received the error Could not load file or assembly 'Microsoft.ReportViewer.Common, Version=11.0.0.0 . I tried to search that DLL on my machine but couldn't. when project is running in visual studio, In Debug-> Windows->Module the file is not listed however in global assembly cache that file is installed but I don't know how its installed to global cache and from where . I found one solution that I had to install ReportViewer.msi from microsoft package but if i install this package it asks me to install SQL Server 2012 which I dont wan't. Could any one help me to resolve this issue. Thanks
Dont know if this is good to anyone, but search all these dlls:
Microsoft.ReportViewer.Common.dll
Microsoft.ReportViewer.ProcessingObjectModel.dll
Microsoft.ReportViewer.WebForms.dll
Microsoft.ReportViewer.WinForms.dll
Microsoft.ReportViewer.DataVisualization.dll
You find them in C:\Windows\assembly\GAC_MSIL\..., and then put them in the references of your project.
For each of them say: local copy, and check for 32 or 64 bit solution.
You can install the Microsoft Report Viewer 2012 Runtime and change your references so they point to the ones installed by the runtime.
http://www.microsoft.com/en-gb/download/details.aspx?id=35747
I have installed the runtime without it asking for SQL Server 2012. Before installing try uninstalling any previous versions of report viewer.
As Microsoft.ReportViewer.2012.Runtime has Microsoft.ReportViewer.WebForms, Microsoft.ReportViewer.Common and Microsoft.ReportViewer.ProcessingObjectModel libraries, just run this command on PM Console:
Install-Package Microsoft.ReportViewer.2012.Runtime
Note : If you want to completely remove the old Microsoft.ReportViewer.xxx references, you can remove them from Manage NuGet Packages>Installed Packages menu and then remove the related lines from packages.config file in your project. After that it will not comeback again during building of the project.
Could not load file or assembly 'Microsoft.ReportViewer.Webforms'
or
Could not load file or assembly 'Microsoft.ReportViewer.Common'
This issue occured for me in Visual studio 2015.
Reason:
the reference for Microsoft.ReportViewer.Webforms dll is missing.
Possible Fix
Step1:
To add "Microsoft.ReportViewer.Webforms.dll" to the solution.
Navigate to Nuget Package Manager Console as
"Tools-->NugetPackageManager-->Package Manager Console".
Then enter the following command in console as below
PM>Install-Package Microsoft.ReportViewer.Runtime.WebForms
Then it will install the Reportviewer.webforms dll in "..\packages\Microsoft.ReportViewer.Runtime.WebForms.12.0.2402.15\lib" (Your project folder path)
and ReportViewer.Runtime.Common dll in "..\packages\Microsoft.ReportViewer.Runtime.Common.12.0.2402.15\lib". (Your project folder path)
Step2:-
Remove the existing reference of "Microsoft.ReportViewer.WebForms".
we need to refer these dll files in our Solution as "Right click Solution >References-->Add reference-->browse ".
Add both the dll files from the above paths.
Step3:
Change the web.Config File to point out to Visual Studio 2015.
comment out both the Microsoft.ReportViewer.WebForms and Microsoft.ReportViewer.Common version 11.0.0.0 and Uncomment both the Microsoft.ReportViewer.WebForms and Microsoft.ReportViewer.Common Version=12.0.0.0. as attached in screenshot.
Microsoft.ReportViewer.Webforms/Microsoft.ReportViewer.Common
Also refer the link below.
Could not load file or assembly 'Microsoft.ReportViewer.WebForms'
You can download the nuget package too.
I had the same problem for Winforms.
The solution for me is:
Install-Package Microsoft.ReportViewer.Runtime.Winforms
Simply install Microsot.ReportViewer.2012.Runtime nuget package as shown in this answer https://stackoverflow.com/a/33014040/2198830
Add Microsot.ReportViewer 2010 or 2012 in prerequisite of setup project then it first install Report Viewer if it's not present in "C:\Windows\assembly\GAC_MSIL..." and after installing, it installs set up project
In my case, the 'Microsoft.ReportViewer.Common.dll' assembly is not required for my project, so I simply removed all references (Project -> Add Reference... -> ...) (all requirements from Publish tab the VS2013 removed automatically) and all works properly.
I Had the same problem.
The solution for me is:
You must have the same version of: Microsoft.ReportViewer.ProcessingObjectModel registred in C:\Windows\assembly\GAC_MSIL\Microsoft.ReportViewer.ProcessingObjectModel,
like you have registraded in web.config in developer server:
In my case i was only registred the 13. version in my prodution server and i have the 12. version in developer server.
the solution is install the version 12. in the prodution server too
the version 12. :
https://download.microsoft.com/download/A/1/2/A129F694-233C-4C7C-860F-F73139CF2E01/ENU/x86/ReportViewer.msi
Then now i have the version 12. in the prodution and the report work fine.
*** Remember to reset your IIS after instalation
I resolved this problem, searching the dll's file in C:\Windows\assembly\GAC_MSIL\ and copied to bin directory of the proyect deployed. That work for me.
Although rather late, but you can manually download the required DLLs from nuget at the following link:
https://www.nuget.org/packages/Microsoft.ReportViewer.Runtime.Common/12.0.2402.15
Open the file .Rar Archive, extract the dlls and copy them manually to the bin folder of your publish.
This solution worked for me. Hope that helps !!
I solve it by download the reportviewer.exe and install it.
After the installation, all related assemblies will be available in C:\Windows\assembly\GAC_MSIL, then you can refer it in web config
I currently have installed Visual Studio 2008, Version 9.0.30729.4462, and I am running into some fairly odd issues that I believe are all linked.
1. When building my solution, I get 5-10 of these output in the debug output:
Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".
All of the .csproj files of the projects contain toolsversion="3.5".
2. When trying to access the Security tab in the project properties, I get the following error:
Visual Studio was unable to determine the Code Access Security (CAS) permissions that are applicable to your project. The most likely cause is that your project references a strongly-named assembly that defines custom permissions, but that is not properly installed in the global assembly cache (GAC). To correct this, try the following:
1. Ensure that any custom permissions defining assemblies referenced by your project have been properly installed to the GAC. If any of these assemblies have been rebuilt or have had their version numbers modified, you must install the new assemblies in the GAC.
2. Restart Visual Studio.
Looking for solutions on here indicate that this is a typically a toolsversion 4.0 problem; however, like I said, all of my projects have 3.5 set in the csproj files.
Where should I start troubleshooting?
Both of these problems were related to the toolsversion="4.0" issue. I have a lot of projects integrated into my solution, so I did a search for "toolsversion=" on my solution directory. It turns out a few of my .csproj project files were indeed set to 4.0. Once all of the projects were set to 3.5, the security tab came back, and I didn't receive any more errors when compiling.
I recently developed a minor Excel 2010 Add-in in the Visual Studio 2011 beta and tried to deploy the solution right now. I selected the .NET Framework 4 as a prerequisite and setup.exe downloads it, if it is not yet installed on the target computer.
But I am getting headaches when trying to catch the "Tools for Office Runtime" into the dialog "Prerequisites" in the Publish tab when building. The strange thing is: In my Office, there was an old 2010 Visual Studio installation, that HAS this setting, I can select the entry, build it and voilá: The runtime is downloaded.
How can I tell Visual Studio: Look, I need this runtime, please check it before installing it. Because right now, setup.exe installs the add-in and it crashes on the first Excel start.
Futher information:
I use click-once deployment
C# VSTO add-in
Targetting Excel 2010
Edit
I think I found a solution for this:
I copied the VSTOR4 directory from my office PC located at ''C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bootstrapper\Packages'' and placed it on my developer notebook at the same location. Result: not found
I copied it to ''C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages''
I edited my project.csproj to include the following setting:
<BootstrapperPackage Include="Microsoft.VSTORuntime.4.0">
<Visible>False</Visible>
<ProductName>Microsoft Visual Studio 2010 Tools for Office Runtime %28x86 and x64%29</ProductName>
<Install>true</Install>
</BootstrapperPackage>
The question is: Is this really the right way? Will there be problems that I didn't think of right now? Why isn't there an option to just download additional bootstrappers (there is, but for .NET 2.0 and some MDAC component I don't use)?
VSTO deployment just is painful as it is and not straight forward comparing to a simple "MSI Installer, done" procedure. Having to deal with these kind of issues really makes me kinda uncomfortable about the whole add-in architecture, but that's another story for another day.
Although you did it manually, it will work fine. Alternately you can go to project properties, Publish tab and click the pre-requisites button to bring up the pre-requsites dialog where you should be able to see VSTOR40 along with other bootstrapper components. If you don't see a particular one there, two possible reasons could be:
You don't have the bootstrapper package in your C:\Program Files (x86)\Microsoft SDKs\Windows\v8.0A\Bootstrapper\Packages folder (replace with v7.0 for VS2010)
Your product.xml (available in the above location) contains incorrect information.
One side note: You should check your product.xml file for HomeSite attribute and make sure you have that set to proper "fwlink" provided by Microsoft for that package. fwlinks are basically persistent web links from where a package can be downloaded by the ClickOnce installer, so that you don't have to distribute it with your product. Use Google to find out fwlinks of different bootstrapper packages.