What causes the error: The "NgenLocalized" parameter is not supported - visual-studio

My project is a Visual Studio Extension. The solution contains multiple projects and references multiple NuGet packages.
On building the solution, I am getting the two errors:
error MSB4064: The "NgenLocalized" parameter is not supported by the
"GenerateFileManifest" task. Verify the parameter exists on the task,
and it is a settable public instance property.
error MSB4063: The "GenerateFileManifest" task could not be
initialized with its input parameters.
The complete errors are:
C:\Users\Phil\.nuget\packages\microsoft.vssdk.buildtools\16.3.2093\tools\VSSDK\Microsoft.VsSDK.targets(685,88): error MSB4064: The "NgenLocalized" parameter is not supported by the "GenerateFileManifest" task. Verify the parameter exists on the task, and it is a settable public instance property.
C:\Users\Phil\.nuget\packages\microsoft.vssdk.buildtools\16.3.2093\tools\VSSDK\Microsoft.VsSDK.targets(685,5): error MSB4063: The "GenerateFileManifest" task could not be initialized with its input parameters.
I get these errors build a release or a debug build.
What do these error mean and how can I get rid of them?
Strangely, if I simply start debugging, it builds without the errors and starts visual studio. However, in that case, I cannot load my package.
The activity log shows the error:
SetSite failed for package [MultiLanguagePackage]
Source: "MultiLanguageWPF"
Description: Method not found: "Microsoft.VisualStudio.Threading.JoinableTaskFactory Microsoft.VisualStudio.Shell.AsyncPackage.get_JoinableTaskFactory()".
System.MissingMethodException: Method not found: "Microsoft.VisualStudio.Threading.JoinableTaskFactory Microsoft.VisualStudio.Shell.AsyncPackage.get_JoinableTaskFactory()".
at MultiLanguageWPF.MultiLanguagePackage.<InitializeAsync>d__2.MoveNext()
at System.Runtime.CompilerServices.AsyncTaskMethodBuilder.Start[TStateMachine](TStateMachine& stateMachine)
at MultiLanguageWPF.MultiLanguagePackage.InitializeAsync(CancellationToken cancellationToken, IProgress`1 progress)
at Microsoft.VisualStudio.Shell.AsyncPackage.<>c__DisplayClass19_0.<<Microsoft-VisualStudio-Shell-Interop-IAsyncLoadablePackageInitialize-Initialize>b__1>d.MoveNext()
--- End of stack trace from previous location where exception was thrown ---
at Microsoft.VisualStudio.Services.VsTask.RethrowException(AggregateException e)
at Microsoft.VisualStudio.Services.VsTask.InternalGetResult(Boolean ignoreUIThreadCheck)
at Microsoft.VisualStudio.Services.VsTask.GetResult()</description>
That might be a related error, or it might not be.

error MSB4064: The "NgenLocalized" parameter is not supported by the
"GenerateFileManifest" task. Verify the parameter exists on the task,
and it is a settable public instance property.
error MSB4063: The "GenerateFileManifest" task could not be
initialized with its input parameters.
Can't reproduce exactly same issue in my machine cause I lack the necessary enough info about your project. But I guess maybe this's one issue about the Microsoft.VSSDK.BuildTools package with 16.3.2093 version.
Some tests and discovery:
Msbuild use targets to manage the build process. We can consider msbuild target as the group of msbuild tasks. The task is a unit of executable code used by MSBuild to perform atomic build operations.
I opened the Microsoft.VsSDK.targets(version ) file at line 685 and found content below:
<Target Name="GenerateFileManifest"
Outputs="$(FileManifest)"
DependsOnTargets="$(GenerateFileManifestDependsOn)">
<GenerateFileManifest FileItems="#(VsixSourceItem)" FileManifest="$(FileManifest)" NgenLocalized="$(NgenLocalized)">
<Output TaskParameter="FileManifest" ItemName="FileWrites" />
</GenerateFileManifest>
</Target>
So it's obvious during build process of your vsix project, it will call GenerateFileManifest target, and this target will call and execute GenerateFileManifest task.
See this and we can better understand what the task means and what it really does for us during build process. To execute the GenerateFileManifest task actually is similar to call the method from GenerateFileManifest class. And according to FileItems="xxx" FileManifest="xxx" NgenLocalized="xxx" these three input parameters, this GenerateFileManifest class should have three public property. (While it actually doesn't have public property NgenLocalized defined in GenerateFileManifest class)
Then another line in Microsoft.VsSDK.targets file indicates this class from assembly $(VsSDKCommonAssemblyFile), it's actually Microsoft.VisualStudio.Sdk.BuildTasks.dll in the same folder. (C:\Users\xxx\.nuget\packages\microsoft.vssdk.buildtools\16.3.2093\tools\VSSDK\)
<UsingTask TaskName="FindVsixManifest" AssemblyFile="$(VsSDKCommonAssemblyFile)" />
After view the structure of this assembly, I can't find the expected NgenLocalized public property. So it's the original cause of the issue in my opinion.
Suggestions:
If this issue can be reproduced in simple vsix project, feel free to report this issue
by Help=>Send feedback=>Report the problem to report to Developer Community.
I think this issue comes from the 16.3.2093 package, the Microsoft.VsSDK.targets is not compatible perfectly with the Microsoft.VisualStudio.Sdk.BuildTasks.dll. So I think you can use previous version of this package.(16.2.3073 or earlier, in my machine I use 16.1.3132 version actually and it works well)
Hope it helps:)

Related

TFS/C#: Logging a custom warning during the build process

I am hacking around a problem we've created for ourselves. What I would like to do is log a warning in our TFS builds for any code that is instantiating a specific class. I don't want a run time warning (I've got one in place already), I want a build time warning that ProjectX is using BadClass.cs. The idea being it will give us an additional place to see things that need to be fixed once our hack is no longer needed.
So something like this:
public class BadClass
{}
public class OkClass
{}
public class MyBadService
{
var a = new BadClass(); <-- Logs a warning to the build output
}
public class MyOkService
{
var a = new OkClass(); <-- Does not log a warning
}
Edit:
I do not like the idea of using Obsolete; its a misnomer. We've already got code with Obsolete attributes and this would get lost in the noise. I don't want a generic warning that I can't control the message for. I want bright neon signs with klaxons firing and a thousand exclamation points in the message. Basically everything I can do short of failing the build. I'm using the #warning precompiler directive right now and its mostly doing what I want but it requires a human to remember to add the warning. I'm looking for something more automagic. I've seen third party libraries do stuff like this so I know its possible.
Why not just use the Obsolete attribute? It can generate a build warning for you:
https://learn.microsoft.com/en-us/dotnet/api/system.obsoleteattribute?view=netframework-4.8
You can even make it emit an error too if you want.
The answer could be negative I think.
It seems that you use or call msbuild.exe to build your C# projects. But as far as I know, MSBuild in fact calls csc.exe to build C# projects in build time.
So actually what you want is logging a warning when the compiler compile the C# code if it recognize somewhere in your code uses the BadClass in build time.
If you have the source code of BadClass in the same solution, add a project reference format to the xx.csproj which contains BadClass, and set a #warning in the BadClass it may generate the warning in build time.
But I think the scenario you're in is something like: You developed one Assembly and distribute it to your user, so you want it generates a warning when the user calls one BadClass in your assembly and builds his own project to remind him of taking care when using this bad class. If so, this is impossible for msbuild AFAIK. If I misunderstand anything, feel free to know me know :)
Update:
As Daniel and Johnson said, ObsoleteAttribute is enough to do this. Though no valid way to generate warnings from msbuild aspect directly, but msbuild will call C# compiler during build process, so generates a compiler warning can output to build output window.

Visual Studio Code Cannot Configure Correctly

For some reason, most likely because I do not know how to configure Visual Studio Code. We are talking about the free light version.
It is always showing an error of some type. I am new to this product, NOT VS but this version of it.
How do we set this IDE up correct to work with it?
Here is my current error.
Downloading and configuring the .NET Core Debugger...
Telemetry is: Enabled
log : Restoring packages for C:\Users\Erik Little\.vscode\extensions\ms-vscode.csharp-0.3.7\coreclr-debug\project.json...
info : Committing restore...
log : Lock file has not changed. Skipping lock file write. Path: C:\Users\Erik Little\.vscode\extensions\ms-vscode.csharp-0.3.7\coreclr-debug\project.lock.json
log : C:\Users\Erik Little\.vscode\extensions\ms-vscode.csharp-0.3.7\coreclr-debug\project.json
log : Restore completed in 585ms.
NuGet Config files used:
C:\Users\Erik Little\.vscode\extensions\ms-vscode.csharp-0.3.7\coreclr-debug\NuGet.config
Feeds used:
https://www.myget.org/F/dotnet-core/api/v3/index.json
https://api.nuget.org/v3/index.json
https://www.myget.org/F/coreclr-debug/api/v3/index.json
Telemetry is: Enabled
Error: Can not find runtime target for framework 'DNXCore,Version=v5.0' compatible with one of the target runtimes: 'win10-x64, win81-x64, win8-x64, win7-x64'. Possible causes:
1. The project has not been restored or restore failed - run `dotnet restore`
2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 'runtimes' section.
Error:
System.InvalidOperationException: Can not find runtime target for framework 'DNXCore,Version=v5.0' compatible with one of the target runtimes: 'win10-x64, win81-x64, win8-x64, win7-x64'. Possible causes:
1. The project has not been restored or restore failed - run `dotnet restore`
2. The project does not list one of 'win10-x64, win81-x64, win8-x64, win7-x64' in the 'runtimes' section.
at Microsoft.DotNet.ProjectModel.BuildWorkspace.GetRuntimeContext(ProjectContext context, IEnumerable`1 runtimeIdentifiers)
at Microsoft.DotNet.Tools.Publish.PublishCommand.<>c__DisplayClass71_0.<SelectContexts>b__1(ProjectContext c)
at System.Linq.Enumerable.WhereSelectListIterator`2.MoveNext()
at System.Collections.Generic.List`1..ctor(IEnumerable`1 collection)
at System.Linq.Enumerable.ToList[TSource](IEnumerable`1 source)
at Microsoft.DotNet.Tools.Publish.PublishCommand.TryPrepareForPublish()
at Microsoft.DotNet.Tools.Publish.PublishCommand.<>c__DisplayClass0_0.<Run>b__0()
at Microsoft.DotNet.Cli.CommandLine.CommandLineApplication.Execute(String[] args)
at Microsoft.DotNet.Tools.Publish.PublishCommand.Run(String[] args)
dotnet exited with error code 1
Error while installing .NET Core Debugger.
They make it seem so easy to set up but there is always something that i am missing. I have a very good thought that I am not setting up the configuration file correctly because it looks strange to me. Looks like all JS.
Also if I point to a folder that I work in with no issues at all with visual studio enterprise edition I always get this error
eslintrc-error
It keeps looking for eslintrc but i have looked everywhere to resolve this.
I've posted a snapshot of this issue as well.
I know is must be a config issue.
I do not even know what eslintrc is.
Please advise.
It's a linter for ecma... the rc file configures its options.
So you're aware code is an editor, not really an IDE. If you're looking for free I'd suggest Visual Studio Community.

Error executing task CreateEmbeddedResources: Task does not have property "BundleResources" defined

I am converting an existing Xamarin.iOS project to unified api (64 bit compatible), within my project a 3rd party project exists and after converting to unified I am facing a build/compile time error saying like "Error: Error executing task CreateEmbeddedResources: Task does not have property "BundleResources" defined (3rdPartyLibraryiOS)"
I have tried applying http://forums.xamarin.com/discussion/comment/115358/#Comment_115358 solution, which worked for many but unfortunately Its not working for me, If I try this solution then my 3rd party project is getting treated as not an unified one!, If I revert then this error will occur. Got stuck hear.
Any help in resolving this is much appreciated in advance.

Building a Visual Studio Package based on another one

I want to add my own project type based on IronStudio. So,
I downloaded the source for and compiled the latest version of IronPython, then
I created a new Visual Studio Package.
I added the Templates\Projects\MyProject folders, and added a file to it, and set its property "Include in VSIX" to true.
Then modified the main Package class to be derived from IronStudio's PythonProjectPackage instead, and set the ProvideProjectFactory property:
[ProvideProjectFactory(
typeof(PythonProjectFactory),
"Django Project",
"Django Project Files (*.myproj);*.myproj",
"myproj", "myproj",
#"Templates\Projects\MyProject",
LanguageVsTemplate="MyProject")]
public sealed class MyPackage : PythonProjectPackage
And ran it. But MyProject isn't showing up in the project templates. Why not?
The generated .pkgdef file looks like this:
[$RootKey$\InstalledProducts\VSPackage3Package]
#="#110"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"PID"="1.0"
"ProductDetails"="#112"
"LogoID"="#400"
[$RootKey$\Packages\{5cd7435c-7461-459f-80bc-c0c79e9d462f}]
#="Microsoft.VSPackage3.VSPackage3Package, VSPackage3, Version=1.0.0.0, Culture=neutral, PublicKeyToken=a4f1577d825253f8"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="Microsoft.VSPackage3.VSPackage3Package"
"CodeBase"="$PackageFolder$\VSPackage3.dll"
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}]
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\Extensions]
"py"=dword:00000020
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a701-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a702-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\Editors\{888888c4-36f9-4453-90aa-29fa4d2e5706}\LogicalViews]
"{7651a703-06e5-11d1-8ebd-00a0c90f26ea}"=""
[$RootKey$\CLSID\{888888fd-3c4a-40da-aefb-5ac10f5e8b30}]
#="Microsoft.IronPythonTools.Project.PythonGeneralPropertyPage"
"InprocServer32"="$WinDir$\SYSTEM32\MSCOREE.DLL"
"Class"="Microsoft.IronPythonTools.Project.PythonGeneralPropertyPage"
"CodeBase"="$PackageFolder$\VSPackage3.dll"
"ThreadingModel"="Both"
[$RootKey$\Projects\{888888a0-9f3d-457c-b088-3a5042f75d52}]
#="PythonProjectFactory"
"DisplayName"="My Project"
"DisplayProjectFileExtensions"="My Project Files (*.myproj);*.myproj"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"DefaultProjectExtension"="myproj"
"PossibleProjectExtensions"="myproj"
"ProjectTemplatesDir"="$PackageFolder$\Templates\Projects\MyProject"
"Language(VsTemplate)"="MyProject"
[$RootKey$\NewProjectTemplates\TemplateDirs\{5cd7435c-7461-459f-80bc-c0c79e9d462f}\/1]
#="My Project"
"SortPriority"=dword:00000064
"TemplatesDir"="$PackageFolder$\Templates\Projects\MyProject"
[$RootKey$\Projects\{888888a0-9f3d-457c-b088-3a5042f75d52}]
#="PythonProjectFactory"
"DisplayName"="IronPython"
"DisplayProjectFileExtensions"="IronPython Project Files (*.pyproj);*.pyproj"
"Package"="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"DefaultProjectExtension"="pyproj"
"PossibleProjectExtensions"="pyproj"
"ProjectTemplatesDir"="$PackageFolder$\.\NullPath"
"Language(VsTemplate)"="IronPython"
[$RootKey$\NewProjectTemplates\TemplateDirs\{5cd7435c-7461-459f-80bc-c0c79e9d462f}\/1]
#="IronPython"
"SortPriority"=dword:00000064
"TemplatesDir"="$PackageFolder$\.\NullPath"
[$RootKey$\Services\{b98e41c4-581e-3532-beee-06829b683d39}]
#="{5cd7435c-7461-459f-80bc-c0c79e9d462f}"
"Name"="IPythonStarter"
I just want to get the bare bones up and running so I can start overriding some functionality (like the Add New Item dialog).
Update:
Reading my initial analysis once again increases my impression that some of the required components are missing (e.g. a dedicated ProjectFactory) and/or wired up incorrectly - from the MSDN documentation of the ProvideProjectFactoryAttribute Class:
ProvideProjectFactoryAttribute declares that a package provides a project factory.
And further:
If a VSPackage declares that it provides a project factory, it should create the factory and offer it to Visual Studio in the Initialize method of the Package-derived class.
You package is declaring to provide PythonProjectFactory, but (likely) doesn't offer it to VS, rather it is offered by the IronPython package. In turn you are providing arguments within the ProvideProjectFactory attribute list which PythonProjectFactory won't know about when asked for by VS.
Consequently you should at least provide a dedicated ProjectFactory yourself as per the walkthrough, wire up the classes accordingly and see how this turns out regarding the issues outlined below.
Initial analysis:
There appear to be several issues here at first sight - have you followed any tutorial on how to do this? In case, please note that some of those easily discoverable via search engines are outdated still. Either way I'd try working through and/or comparing your result with Walkthrough: Part 1 - Creating a Basic Project System from the MSDN documentation for VS 2010; please note that even this one is claimed to be outdated a bit according to the Community Content section on the bottom of the page.
Here is what I'd look into myself given the code you present, comparing with the walkthrough on the fly for more insights:
You realized already that the duplicate fragment starting with the GUID above PythonProjectFactory doesn't make sense - this is essentially trying to register two packages at once, which, even if allowed at all syntactically (which I doubt), can't possibly work like so due to both being registered with the same GUID [cross checking with the sample file in section Examining the Template Registration confirms this suspicion, as expected there is only one such fragment].
Please note that the GUID in question is the one identifying PythonProjectFactory (as per the respective source code), see below for more on this.
[Guid(PythonConstants.ProjectFactoryGuid)]
public class PythonProjectFactory : ProjectFactory {
Given .pkgdef is a generated file the next question is where this duplication/violation stems from. When two generated artifacts end up with the same GUID the respective definition in the sources is most likely messed up somehow, usually due to copy&paste duplication. Consequently you should verify whether {5cd7435c-7461-459f-80bc-c0c79e9d462f} is defined and referenced as intended, though here might be one or two other causes as well for this, see below.
A Package class needs to be identified by a GUID and the VS wizard generates some already in Guids.cs and references it accordingly on the class definition, however, the following is missing in your fragment [cross checking with the sample fragment in section To register the project template confirms this omission as well]:
[Guid(GuidList.guidMyPackagePkgString)]
public sealed class MyPackage : Package
Likewise it appears incorrect to derive MyPackage from PythonProjectPackage but reference PythonProjectFactory still rather than providing MyFactory as well (including a dedicated GUID), because the latter tells Visual Studio the location of your project template folder [see section Creating a Skeletal Project Factory]:
While it might well be possible to simply reuse all functionality from the base class PythonProjectFactory, inheriting is likely required simply because the factory must have a dedicated GUID too (as outlined in the walkthrough) in order to properly wire up the attribute specified data.
Likely unrelated, but still suspicious is that your two code blocks don't relate, as the Package class definition specifies Django Project Files (*.myproj);*.myproj, yet the result shows My Project Files (*.myproj);*.myproj.
Have you by chance mixed this from different builds or is this really a result of a clean one?
Good luck!
This stackoverflow posting might be helpful: VS2010: VSIX installation doesn't deploy item templates inside it
If this is not what you're looking for, try to see if you're missing something around the creation of custom project templates, I believe that's where the "missing link" is:
For VS 2008:
http://blogs.msdn.com/b/webdevelopertips/archive/2008/12/02/tip-32-did-you-know-how-to-easily-create-your-own-project-templates.aspx
For VS 2010:
http://blog.reybango.com/2010/09/21/how-to-create-html5-website-and-page-templates-for-visual-studio-2010/
and on MSDN:
http://msdn.microsoft.com/en-us/library/s365byhx.aspx
and here is how to create a project
template manually:
http://msdn.microsoft.com/en-us/library/ms185291.aspx
and here is how to create a new item template in VS 2010: http://msdn.microsoft.com/en-us/library/ms247113.aspx
Hope this helps
$PackageFolder$.\NullPath may have something to do with it.

Visual Studio Unit Test - The member specified could not be found

Getting an odd problem with a unit test in my solution. One of the test always fails with the following error message:
The member specified (BuildMap) could not be found. You might need to regenerate your private accessor,
or the member may be private and defined on a base class. If the latter is true, you need to pass the type
that defines the member into PrivateObject's constructor.
BuildMap is private and I have tried regenerating the accessor, changing it to public and recreating the unit test and it continuously fails. The other methods (both public and private) all work fine. BuildMap is also not defined in a base class.
Also tried all the usual things in case VS is messing about, restarting it, clean assemblies, rebuild etc...
Any ideas on the cause?
update 1: This is in Visual Studio 2008 or on the command line mstest tool.
update 2: Tried renaming the BuildMap method and the tests would not build stating it was missing. Appears that Visual Studio/MSBuild is doing the right thing, but somewhere between it and mstest it is breaking.
Oddly enough when I changed the method from static to not static the issue resolved itself. Other private static methods work fine though.
Still not sure of the cause but that is the resolution.

Resources