I am using the DotNetCore.1.0.0-VS2015Tools.Preview2.exe with Visual Studio Update 3.
I am unable to migrate code to read settings in the appsettings.json file from an MVC6 app.
The code uses the #inject Microsoft.Extensions.OptionsModel.IOptions Settings syntax in a razor file to read the configuration.
The only version of Microsoft.Extensions.OptionsModel.IOptions available is rc1, whereas the Microsoft.Extensions.Options.ConfigurationExtensions version is rc2.
Therefore I am getting the 'ambiguous call' error referred to in a related .net github issue:
Error CS0121 The call is ambiguous between the following methods or properties:
Microsoft.Extensions.DependencyInjection.OptionsServiceCollectionExtensions.Configure and Microsoft.Extensions.DependencyInjection.OptionsConfigurationServiceCollectionExtensions.Configure. This error is about using ANY rc1 version concurrently with any rc2 version of any library/component listed in project.json.
leaving out the Microsoft.Extensions.OptionsModel.Options part I get this further error:
Could not load type 'Microsoft.Extensions.DependencyInjection.ServiceCollectionExtensions' from assembly 'Microsoft.Extensions.DependencyInjection.Abstractions, Version=1.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'.
Of course, I realize this is part of the worst (or most visible) release mess in ms-land history. And such is the cost of progress. But I still would like to know the answer, please.
Related
I'm attempting to programmatically build a project which uses C#7, and therefore MSBuild 15, but this task is failing seemingly because of mismatched assembly references.
Here is my code:
string projectFilePath = Path.Combine(args.Any() ? args.First() :#"C:\Users\newsoni\Documents\Visual Studio 2017\Projects\ConsoleApp2\ConsoleApp2.sln");
ProjectCollection pc = new ProjectCollection();
Dictionary<string, string> globalProperty = new Dictionary<string, string>();
globalProperty.Add("Configuration", "Debug");
globalProperty.Add("Platform", "x86");
BuildParameters bp = new BuildParameters(pc);
bp.Loggers = new ILogger[] { new Logger(), new ConsoleLogger(), };
BuildRequestData BuidlRequest = new BuildRequestData(projectFilePath, globalProperty, "4.0", new string[] { "Build" }, null);
BuildResult buildResult = BuildManager.DefaultBuildManager.Build(bp, BuidlRequest);
Here is the error message:
C:\Users\newsoni\Documents\Visual Studio 2017\Projects\ConsoleApp2\ConsoleApp2.sln.metaproj : error MSB4127: The "Error" task could not be instantiated from the assembly "Microsoft.Build.Tasks.v4.0, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a". Please verify the task assembly has been built using the same version of the Microsoft.Build.Framework assembly as the one installed on your computer and that your host application is not missing a binding redirect for Microsoft.Build.Framework. Unable to cast object of type 'Microsoft.Build.Tasks.Error' to type 'Microsoft.Build.Framework.ITask'.
C:\Users\newsoni\Documents\Visual Studio 2017\Projects\ConsoleApp2\ConsoleApp2.sln.metaproj : error MSB4060: The "Error" task has been declared or used incorrectly, or failed during construction. Check the spelling of the task name and the assembly name.
Here is a link to a project you can use to recreate the issue:
https://drive.google.com/a/xibis.com/file/d/0B-mqMIMqm_XHcVRJQmtxQkd1b3c/view?usp=sharing
You will have to change the path in the code to a project on your own machine, but it doesn't seem to matter if this is a VS 2017 project or earlier.
One other thing that may or may not be relevant, I noticed that the Microsoft.WebApplication.Build.Tasks.Dll in this folder:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0\WebApplications
Still seems to be referencing Microsoft.Build.Framework.dll version 14, not 15 as I would have expected.
It turns out there are two issues in my test project. The first is due to the naming of the project.
However there is a second issue which is due to the references not being correct. To use MSBuild 15 programmtically you must install the following packages:
Install-Package Microsoft.Build -Version 15.1.1012
Install-Package Microsoft.Build.Framework -Version 15.1.1012
Install-Package Microsoft.Build.Tasks.Core -Version 15.1.1012
Install-Package Microsoft.Build.Utilities.Core -Version 15.1.1012
Install-Package Microsoft.Net.Compilers -Version 2.2.0
There is one more step which is nuts and completely undiscoverable. You must now add a reference to this DLL which should be relative to your solution folder:
packages\Microsoft.Net.Compilers.2.2.0\tools\Microsoft.Build.Tasks.CodeAnalysis.dll
I opened a support ticket with Microsoft and they have confirmed that this is a bug in Visual Studio 2017.
They are aiming to get a fix for this into update 3 for Visual Studio, but this may slip.
This issue tracks the bug:
https://github.com/Microsoft/msbuild/issues/2194
There is no workaround at present for this API, but you can invoke the MSBuild exe using Process as an alternative.
If you have MSBuild installed on your PC, either directly or through Visual Studio, the proper fix is to use the package Microsoft.Build.Locator which will find that installed version and execute the build using it.
Install these packages
Microsoft.Build
Microsoft.Build.Framework
Microsoft.Build.Locator
The first 2 are needed so that the code can compile but should be excluded from the project output.
In your application startup add the following line of code, this only has to run once.
Microsoft.Build.Locator.MSBuildLocator.RegisterDefaults();
Remove any additional binding redirects in your app.config that are specific to Microsoft.Build or other build libraries. The call to the Microsoft.Build.Locator assembly will ensure that these redirects take place automatically.
References
Update an existing application for MSBuild 15
Github MSBuildLocator.
Hi we have recently upgraded to NSB 4.2 from 3.5.
After the upgrade NSB logs a warning
Message header 'SomeNamespace.ISomeEvent__impl, NServiceBus.Scheduling.Messages__impl, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null' was mapped to type 'SomeNamespace.ISomeEvent__impl' but that type was not found in the message registry, please make sure the same message registration conventions are used in all endpoints, specially if you are using unobtrusive mode. MessageId: 37cbec38-7957-4b7a-b313-804f6ed3b6fd\37679827
If i debug i can see we have a entry in message registry for SomeNamespace.ISomeEvent
But the type it looks for is SomeNamespace.ISomeEvent__impl.
We have not changed our unobtrusive settings after the upgrade, so question is what has changed?
I can see the logging has changed in change set 5f1c72ba, seems the file has been renamed or something so cant seem to see full history.
Have we always had the problem, but only recently logging behavior in NSB has changed?
I am having this annoying error while running my Nhibernate project. It was running okey and all of a sudden it just start asking for a file in this path "d:\CSharp\NH\NH\nhibernate\src\NHibernate\Bytecode\AbstractBytecodeProvider.cs" and when cancel, it throws an exception saying it says
Unable to load type 'NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle' during configuration of proxy factory class.
Possible causes are:
- The NHibernate.Bytecode provider assembly was not deployed.
- The typeName used to initialize the 'proxyfactory.factory_class' property of the session-factory section is not well formed.
Solution:
Confirm that your deployment folder contains one of the following assemblies:
NHibernate.ByteCode.LinFu.dll
NHibernate.ByteCode.Castle.dll
It is become frustrating for me... need help please -:)
Make sure that you have following dlls copied to the output folder and loaded by your process:
NHibernate.ByteCode.Castle.dll
Castle.Core.dll
NHibernate.dll
Iesi.Collections.dll
log4net.dll
And your NHibernate configuration has this line:
<property name="proxyfactory.factory_class">
NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle
</property>
As an option, you can try to upgrade to latest version of NHibernate - 3.2. They have a built in proxy generator so it should be simpler for you. You will not need these additional dlls. Just remove the config line above if you use NHibernate 3.2.
If for some reasons you can not upgrade to 3.2 you may consider using different byte code providers. NHibernate supports 3 of them out of the box. Try LinFu or Spring:
NHibernate.ByteCode.Castle.ProxyFactoryFactory
NHibernate.ByteCode.LinFu.ProxyFactoryFactory
NHibernate.ByteCode.Spring.ProxyFactoryFactor
Upgrade to the latest version and you will not need an external proxyfactory anymore.
I was trying to use ajax control toolkit in sharepoint 2010, but i get some errors. I found that the last release of the toolkit doesn't work with SP2010, so i downloaded the version 30930 found at http://ajaxcontroltoolkit.codeplex.com/releases/view/33804
Then i modified the web.config adding this:
<assemblies>
....
<add assembly="AjaxControlToolkit, Version=3.0.30930.28736, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e" />
I added the dll to the references (creating a new tab in the toolbox and browsing the dll file) and started using the ajax controls in my web part. It deploys without problems, but when i run my webpage i get this error:
Server Error in '/' Application.
--------------------------------------------------------------------------------
Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not load file or assembly 'AjaxControlToolkit, Version=3.5.40412.0, Culture=neutral, PublicKeyToken=28f01b0e84b6d53e' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Which points to the first line of my webpart ascx file
Any ideas?
It looks like your web part references version 3.5.40412.0 of the AJAX Control Toolkit in an #Register directive. Since you want to use version 3.0.30930.28736, and since that version is properly referenced in your web.config, you should register the toolkit in your web part using its assembly name and namespace only, e.g.:
<%# Register Assembly="AjaxControlToolkit" Namespace="AjaxControlToolkit"
TagPrefix="ajax" %>
Take a look at this blog article which explains how to use the Ajax Control Toolkit with SharePoint 2010 http://www.inspiredbytechnology.com/index.php/2010/10/28/using-the-ajax-control-toolkit-with-sharepoint-2010/
I just installed VS2010 RC and launched the FullDuplex sample from NServiceBus 2.0.0.1145 and it ran fine. I then changed the target framework of each project in the solution to ".NET Framework 4", recompiled and launched in the debugger and received the following exception:
System.InvalidOperationException was unhandled
Message=No endpoint configuration found in scanned assemblies. This usually happens when NServiceBus fails to load your assembly contaning IConfigureThisEndpoint. Try specifying the type explicitly in the NServiceBus.Host.exe.config using the appsetting key: EndpointConfigurationTypeScanned path: C:\Development\Personal\ThirdParty\NServiceBus\samples\FullDuplex\MyClient\bin\Debug\
Source=NServiceBus.Host
StackTrace:
at NServiceBus.Host.Program.ValidateEndpoints(IEnumerable`1 endpointConfigurationTypes) in d:\BuildAgent-02\work\672d81652eaca4e1\src\host\NServiceBus.Host\Program.cs:line 189
at NServiceBus.Host.Program.GetEndpointConfigurationType() in d:\BuildAgent-02\work\672d81652eaca4e1\src\host\NServiceBus.Host\Program.cs:line 171
at NServiceBus.Host.Program.Main(String[] args) in d:\BuildAgent-02\work\672d81652eaca4e1\src\host\NServiceBus.Host\Program.cs:line 32
InnerException:
You have to provide the correct supported runtime version in the NServiceBus.Host.exe.config
for example:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="EndpointConfigurationTypeScanned" value="d:\w\ServiceBusTest\"/>
</appSettings>
<startup>
<supportedRuntime version="v4.0" sku=".NETFramework,Version=v4.0"/>
</startup>
</configuration>
The error is actually saying everything :)
The generic host cannot find an endpoint configuration, probably because it fails to dynamically discover and load your .NET 4 assemblies.
You might need to check out the NServiceBus source code and built it against .NET 4 yourself for it to work.
I had this problem and found that my "Start external program" path for NServiceBus.Host.exe was not the folder with my assemblies in, thus meaning it couldn't find any endpoints. In this case, two options are to point to NServiceBus.Host.exe in the bin folder or use menty's answer and add an EndpointConfigurationTypeScanned into the config.
I was never able to get this completely resolved. I first had to convert all of the NSB projects to set the target framework to 4.0. I then upgraded to the latest ilmerge and added the necessary arguments for it to the build script. Next I had to update NAnt and NUnit configuration files to also work with 4.0. I was finally able to get a successful build and ilmerge but now I get an error related to the framework version of TopShelf when executing the upgraded FullDuplex sample using the newly compiled libraries.
I'm assuming I'll have to get newer TopShelf binaries or get the source and build it myself against the 4.0 framework but I haven't been able to look at it in the last week.
Andreas, are there any plans to update the NSB project itself to the 4.0 framework in the near future?