I have added Catel.Core 3.7, Catel.MVVM 3.7 and Catel.Extensions.Controls 3.7 to my Project but does not have the codesnippets. I have looked in C:\Users\NNUser\Documents\Visual Studio 2013\Code Snippets\Visual C#\My Code Snippets and no Catel folder there. I can neither find any templates.
I got the impression these should be automatically installed, or do I need to install them manually as indicated in the end of this thread. Seems to be available here but are those version independent?
NuGet isn't the right mechanism to deploy code snippets & templates. It only contains the actual binaries when deployed via NuGet.
They should be installed manually as documented here
The code snippets and templates are mostly version independent, but will always work with the latest version.
btw. why are you using v3.7? The latest version is 3.9 and 4.0 is about to be released
Related
I've got an Azure Function app that creates a precompiled DLL (so it uses normal .cs files, not the older .csx method, pre-VS2017). Previously, it was targeting .Net Framework 4.5.2. I updated it to 4.7 so as to use some of the new C# 7 features. I updated my NuGet packages by doing "Update-Package -Reinstall" and verified that they all have the "net47" target set in my packages.config file.
Everything compiles fine. But when I call a function that uses either of 2 HttpRequestMessageExtensions methods, I get an exception. One example of the exception is this:
Method not found: 'System.Net.Http.HttpResponseMessage
System.Net.Http.HttpRequestMessageExtensions.CreateResponse(
System.Net.Http.HttpRequestMessage, System.Net.HttpStatusCode)'.
Here's an example of a tiny test function that will cause the error:
using System.Net;
using System.Net.Http;
public static HttpResponseMessage Run(HttpRequestMessage req)
{
return req.CreateResponse(HttpStatusCode.Accepted, "");
}
Upon calling this function with say Postman, I'll receive the aforementioned exception. I also get a similar method not found exception when I call GetQueryNameValuePairs() on the HttpRequestMessage.
I've tried updating my NuGet packages to the latest, no difference. I've cleaned and rebuilt and restarted a bunch of times, making sure to nuke my bin and obj directories.
I'm not sure what could be the problem. I guess I could downgrade back to .Net 4.5.2 but I'd rather not. For one, I want to use C# 7, and for two, I want to understand what the problem is rather than avoid it.
Update: interesting. The issue seems to be with System.Net.Http. If I lower it to 4.0.0 everything works fine. If I raise it to any higher version I get the issues listed above. I tried selectively lowering each of my packages, one by one, to their previous version number to find this out. I then updated all but this one to the latest version and it fixed the issue.
I also tested it on my side. The issue is related to the latest version of System.Net.Http assembly(4.3.2). If I don't install this package manually or install the earlier versions(4.3.1/4.3.0), the application could work fine.
The CreateResponse method is a extension method which is written in System.Web.Http assembly(version 5.2.3). It seem that it is not compatible with the latest version of System.Net.Http. Please could just skip the error by using the earlier version of System.Net.Http and you can also submit this issue to Microsoft using follow channel.
https://connect.microsoft.com/VisualStudio/Feedback
Interesting. For me, if I got above version 4.0.0 (including 4.1.1 or 4.3.1) I still get the same problem of not finding those extension methods.
The assembly might not be updated during you change the package version. From the bin\Debug\net47 folder, we could check the current assembly version we used.
If the modified date of assembly is 2/9/2017, the package version is 4.3.1. If the modified date of assembly is 4/19/2017, the package version is 4.3.2. If the assembly is not the latest version, it could work fine on my side.
In addition, Microsoft.Asp.Net.WebApi.Client package is installed by default when creating an Azure function. System.Net.Http is one of its dependencies. So we don't need to install the System.Net.Http package manually. When running our application, NuGet will choose a right version of System.Net.Http for our application.
I had the same issue running my Azure Function locally and eventually tracked it down to conflicting System.Net.Http assemblies. I created my Azure function from a blank ASP.NET Web App and initially pulled down the System.Net.Http NuGet package to use within the project. I also pulled down the Microsoft.AspNet.WebApi.Client for use within the project. It did not matter which version of System.Net.Http I tried my project would compile but fail when the request was made.
Eventually, I removed packages I had downloaded, cleaned the build folder and added just the Microsoft.AspNet.WebApi.Client. I noticed that this automatically referenced the System.Net.Http on my machine for my version of the .NET Framework. (C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework). This compiled successfully and I was able to make requests to the function without any exceptions.
Using #Aaron-Newton's insight, I identified that my issue was due to my Azure Functions project referencing a .Net Standard 2.0 class library. I switched it to .Net Framework 4.6 and it started working again. Seems like this is a bug in the Functions tooling.
I've filed a bug with the Functions team here: https://github.com/Azure/Azure-Functions/issues/477
I had the same issue. I spent quite a while to fix this problem.
The cause is that the Azure Functions project is refering to .Net Standard Library with version higher than 1.4.
Bringing down your .Net Standard version to 1.4 or lower would fix the problem.
But this is defintely a bug with Azure Functions SDK. They should fix it.
https://github.com/Azure/azure-webjobs-sdk-script/issues/980
https://github.com/Azure/Azure-Functions/issues/477
I installed the Westwind-Globalization package 2.1 but the libraries installed are misssing the Westwind.Globalization.JavaScriptResourceHandler-class. I downloaded 2.1 from git-hub and compiled the Westwind.Globalization.Web-project anew. Now the class exists and my code works again.
Did I do something wrong or is this class deprecated/discontinued?!
You need to install the Westwind.Globalization.Web package, which includes the JavaScript resource handler. The release version of the libary rearranged the breakout of resources into separate packages. I suspect you had an older, or beta version that came from before when the change was made (a beta most likely).
I am currently working on a project in Orchard. We are looking to wrap up an existing .NET MVC Web application within an Orchard Module. Currently, we are having issues with AutoFac.
The original site was built using AutoFac 3.5, however the latest stable version of Orchard is still running on 3.0. The application requires features introduced in 3.3. If I install 3.0 into the module, the features do not work, if I have 3.5 in the module, it produces a conflict.
Can anybody suggest a way of handling this conflict? Or, is it safe to upgrade AutoFac 3.0 in Orchard and if so how should I perform this without breaking it?
Thanks,
If I may suggest, Orchard 1.9 should be released soon™ and it already has dependency on latest stable Autofac 3.5.2. If you don't want to wait you can grab latest repository from GitHub
https://github.com/OrchardCMS/Orchard/tree/1.9-int
It's perfectly stable in my opinion and I find released 1.8.1 to be much more buggy :D.
Copy the web.config file runtime Node from Existing Module (Lucene or Markdown or like) and add the runtime node on conflicts Module Web.Config file. After Compile then clear the Conflict
This should be a simple question but I can't seem to find the answer anywhere.
I've got a project that I'm building to .Net 3.5. I'm trying to include Newtonsoft JSON.Net as a reference, but NuGet is installing a version built to .Net 4.0. This makes it impossible for me to use my compiled assembly in an environment that does not support .Net 4.0.
Is there any way to configure NuGet so that it ensures that the reference is not built to a version of .Net beyond the project settings?
Maybe you can use this answer to a similar question:
Download old version of package with nuget
It says that you can install an old version of a package
You can try to install a version compatible with .NET Framework 3.5, and it will be solved!
;) I hope this helps
NuGet will use the project's target framework to pick the correct assembly from the NuGet package. You cannot override this behaviour.
The latest version of the Json.NET NuGet package (6.0.1) contains an assembly specifically for .NET 3.5 so NuGet should automatically pick that one if your project has a target framework of 3.5.
Changing my project's target framework to 3.5 results in the following element being added to the project:
<TargetFrameworkVersion>v3.5</TargetFrameworkVersion>
This is what NuGet uses to determine which assembly to use.
When Json.NET is installed into this project the Newtonsoft.Json.dll file is referenced from the packages\Newtonsoft.Json.6.0.1\lib\net35 directory. That assembly targets .NET 3.5
I have Awesomium SDK 1.6.6 installed and i want to upgrade it to the 1.7 candidate how could i do that. because when i downloaded the 1.7 i find it is only consists of some files and no setup file included (like the 1.6 one)
We have not created an installer for the Release Candidates of version 1.7. RCs are not stable releases. There will be one again when 1.7 goes stable and 1.6.6 installations will then be able to automatically upgrade to 1.7.
Are you looking to use the .NET wrappers? If so, you should be able to download and extract the files anywhere, then in your project, just add references to Awesomium.Core.dll and either Awesomium.Windows.Forms.dll or Awesomium.Windows.Controls.dll, depending on whether you're using Winforms or WPF. The dlls are located in awesomium_1_7_rc3_v3_sdk_win\wrappers\AwesomiumNET\Assemblies\ within the archive.
I believe the setup.exe you're expecting to see is only used for extracting the files to a specific location and providing you with some helpful links in your start menu, so you aren't missing much by not having it.