Whenever I build my customization, it automatically copies System.IO.Compression.ZipFile in the bin folder. I am not able to figure out which is dependent on this file. Every build I have to delete the file to launch the site.
Is there any solution for this issue?
This happens because you are targeting a .NET framework version that is more recent than the one the rest of the Acumatica code is compiled with. As of now you should target .NET 4.5.2 (even if the documentation mentions that a newer version is required to install Acumatica)
Related
I made a new .NET Class Library solution if TFS, and added a bunch of preexisting classes that were developed for a windows forms application. Basically just dumped the old folder in. The forms app worked fine and the folders in bin were expectedly barren, apart from the exe and the required nuget references. The dll build however copies over libraries all the way from Microsoft.Win32.Primitives.dll, to System.Xml.XPath.XDocument.dll for no apparent reason. I have removed unused references with ReSharper and commented out unnecessary using statements. No difference whatsoever. I don't think it's a problem from the deployment perspective, it's just annoying to have so many files copied over each build. Could it be that the initial presence of Forms just poisoned the new project forever? Any help whatsoever would be much appreciated.
Prevent Visual studio 2017 from copying almost 100 unnecessary system
dlls to output folder for dll project
Please check if your VS2017 is very old and also check if the framework version of your project targets to 4.6 or 4.7.1.
If so, there is an known issue about this issue.
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2. You can check this similar issue.
Suggestion
1) you should first update your VS2017 in case some updates fix it.
2) change the framework version of your project to net framework 4.7.2.(if you do not have net frameowork 4.7.2, you should install it in the VS Installer)
When I try to run (debug) functions in Visual Studio 2017 on one of our machines, the following dialog pops up!
The target framework for the project is <TargetFramework>net461</TargetFramework>. For some reasons I am not able to install .NET 4.7.1 and now I am completely lost. I am sure it was functioning in the past on the same machine. Probably one of the updates caused it.
Any idea how to resolve it?
This is because the latest version of the Azure Functions Tools for Visual Studio now requires .NET Framework 4.7.1 (as of February 2018).
Note that this does not impact the target framework that you compile against - only the target framework your code runs against. Similarly, when you run in Azure, you can expect the .NET runtime version to be .NET Framework 4.7.1 (at the time of writing).
I tried implementing the solution mentioned in comment. However, it didn't work for me. However, reverting the Azure Functions Tools to previous version worked. Thanks Chris for pointing that it was Azure Tools and not any packages that caused it.
If anyone else should come across this.
For me, the issue was the actual func.exe config that needed to be upgraded.
Navigate to:
C:\Users[USER]\AppData\Local\AzureFunctionsTools\Releases[VERSION]\cli
.. my version was 1.4.0
Modify the func.exe.config to match the .net version installed
.. it was 4.7.1
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 have an application that uses unity and the logging application block. I recent checked-out the application from the repository after these assemblies were added and I got a few error. Eventually I installed enterprise library on my pc and it's now working. My question is do I have to install Enterprise Library on every pc that uses it? If so is there a workaround?
The issue is that your project which references the Enterprise Library assemblies is referencing where the Enterprise Library is installed - probably the Program Files directory. Instead of referencing them there, you could add the Enterprise Library references via Nuget, then check the packages into your source control as part of the project. That way you have the project and its dependencies all in one place, and it shouldn't be necessary to install the Enterprise Library everywhere.
Hi I have no idea how I fixed it. I think that my problem was that I was using the dlls and the config exe's from the enterprise library labs. I should have installed ent lib 5 on my pc. I had the same problem in my ci server so I deleted my project from the repository and added it again as my local was working.
So in a nut shell. Install entlib 5 and don't use the dlls from the labs in your project. I don't need to install ent lib in my deployment all I need is to copy the dlls.
I have a solution with reference to Telerik assemblies. The referenced version has been installed on the build server. The issue is that the continuous integration build always succeeded until I upgraded the Telerik assemblies in the solution and on my build server. The build now fails giving the classical:
Could not resolve this reference.
I checked my solution and everything is set to reference the specific version. The most suprising is that if I open the solution locally on the build server, everything will build without a problem... so that means the Telerik assemblies have been published somehow, but for an unknown reason, when MSBuild is called to compile the solution throught the build service, it does not work.
Any ideas?
I had the same problem after updating to the Q3 release.
To solve this, I built the solution with Logging Verbosity set to Diagnostic, and found that MSBuild never bothered to look in the Telerik folder.
So to include that folder in the build, we simply added it by adding a MSBuild argument:
/p:ReferencePath="C:\Program Files\Telerik\RadControls for WPF Q3 2012\Binaries\WPF40"
It's perhaps not the best, and needs to be updated everytime you update RadControls, but it works.
We run the build server on a x86 installation, so Telerik is located under C:\Program Files, but if you run on a x64, it's under C:\Program Files(x86), so if you run several build servers on both x64 and x86 installations, you must specify both path.
Try to remove-then-add reference to updated dlls - you can then see in proj file if there any differences with referenced assembly.
Enable verbose\diag mode for msbuild (/v:diag command line key) and check build logs. Diag mode have very detailed output about referenced library search process.
I normally find it's better to copy the referenced assemblies into the solution and reference them from there. Then the build server and other developers don't need to worry about installing that specific version and you can support multiple projects running different versions of the component.