Here is info about our technical development environment :
-Microsoft Visual Studio Enterprise 2019
-.Net Core 3.1
-DevExpress v21.2.6 platform
PostgreSQL 14.2, compiled by Visual C++ build 1914, 64-bit
Microsoft.AspNet.Providers.Core 2.0.0
Microsoft.EntityFrameworkCore 5.0.15
Microsoft.EntityFrameworkCore.Design 5.0.15
Microsoft.EntityFrameworkCore.Tools 5.0.15
Microsoft.OpenApi 1.2.3
Npgsql 5.0.12
Npgsql.EntityFrameworkCore.PostgreSQL 5.0.10
Swashbuckle.AspNetCore 6.3.0
Since I’m using .Net Core 3.1 , I ensured the following setting:
In Visual Studio 2019, Tools - Nuget Package Manager - Package Manager Settings
Default package management format: Packages.Reference
Within my solution’s directory’s NuGet.config file, I have the following xml markup code:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<config>
<add key="globalPackagesFolder" value=".\packages" />
</config>
<packageSources>
<add key="Nexus" value=http://blahblah.com/nuget-group/ />
</packageSources>
</configuration>
Therefore, the packages directory is at the root of the solution’s directory.
I do Not want the packages directory to be committed to the Git code repository, therefore, if anyone does a fresh brand new pull for the first time said solution code then they will Not have the packages directory.
Therefore, if someone opens up said solution for the very first time in Visual Studio 2019, they will get the following types of errors:
Severity Code
Error NETSDK1064
Description
Package Microsoft.AspNetCore.Http.Abstractions, version 2.2.0 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
Severity Code
Error NETSDK1064
Description
Package Microsoft.CodeAnalysis.Analyzers, version 2.9.4 was not found. It might have been deleted since NuGet restore. Otherwise, NuGet restore might have only partially completed, which might have been due to maximum path length restrictions.
Could someone please tell me how I can go about modifying said configuration in such away that it would create the packages directory if they do Not exists ( preferably some kind of switch setting within the NuGet.config file ) ?
This is not duplicate of this thread, although goal is the same, but the error is not.
I want to build my ASP.NET Core on machine without Visual Studio installed.
I need this, because I am setting GitLab CI/CD.
Just for test purpose I open console I execute dotnet restore and dotnet build in folder where .sln file is. I get the following error in both cases:
C:\Program Files\dotnet\sdk\2.1.4\NuGet.targets(103,5): error : The
local source 'C:\Users\matjaz.cof\.dotnet\NuGetFallbackFolder' doesn't
exist.
Full log:
C:\GitLab-Runner\builds\7cab42e4\0\web\app>dotnet restore
Restoring packages for C:\GitLab-Runner\builds\7cab42e4\0\web\app\App.Web.Core\App.Web.Core.csproj...
Restoring packages for C:\GitLab-Runner\builds\7cab42e4\0\web\app\App.Web.Library.Tests\App.Web.Library.Tests.csproj...
Restoring packages for C:\GitLab-Runner\builds\7cab42e4\0\web\app\App.Web.Core.Tests\App.Web.Core.Tests.csproj...
Restoring packages for C:\GitLab-Runner\builds\7cab42e4\0\web\app\App.Web.Library\App.Web.Library.csproj...
Restoring packages for C:\GitLab-Runner\builds\7cab42e4\0\web\app\App.Web.Hosting\App.Web.Hosting.csproj...
Restore completed in 93,72 ms for C:\GitLab-Runner\builds\7cab42e4\0\web\app\App.Web.Hosting\App.Web.Hosting.csproj.
C:\Program Files\dotnet\sdk\2.1.4\NuGet.targets(103,5): error : The local source 'C:\Users\matjaz.cof\.dotnet\NuGetFallbackFolder' doesn't exist. [C:\GitLab-Runner\builds\7cab42e4\0\web\app\App.Web.sln]
Answer in provided thread says that all I need is Dotnet SDK, which I installed:
C:\GitLab-Runner\builds\7cab42e4\0\web\app>dotnet --version
2.1.4
Folder really doesn't exists on Windows server, but it exists on my development machine (with VS 2017 installed).
I search entire c: on Windows Server for folder NuGetFallbackFolder and found it in c:\Program Files\dotnet\sdk\NuGetFallbackFolder.
Why dotnet restore/build search for folder under username and what do I need to change?
Edited: (#MartinUllrich)
This is the content of c:\Users\matjaz.cof\AppData\Roaming\NuGet\NuGet.Config:
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<add key="nuget.org" value="https://api.nuget.org/v3/index.json" protocolVersion="3" />
</packageSources>
</configuration>
This fallback folder path was used during the 2.0 preview timeframe of .NET Core.
You can delete package sources referencing this directory from the C:\Users\ matjaz.cof\AppData\Roaming\NuGet\NuGet.Config file.
I simply solved it by coping c:\Program Files\dotnet\sdk\NuGetFallbackFolder\ to c:\Users\matjaz.cof\.dotnet\NuGetFallbackFolder\.
I couldn't think of anything else. Maybe uninstalling old .NET Core runtimes and SDKs would also do the trick.
I am trying to make a COM for my old project. The COM is built successfully, but when I tried to use the COM to call some functions, this error comes out:
Mixed mode assembly is built against version 'v2.0.50727' of the
runtime and cannot be loaded in the 4.0 runtime without additional
configuration information.
The old project have some parts in .NET 4.0, and some parts in .NET 3.5. Though I tried to make all parts in .NET 4.0, some third party DLLs I used cannot be rebuilt to higher framework.
I have searched this problem, and all people told me to add a app.config or web.config to the application that:
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0" sku='.NETFramework,Version=v4.0' />
<requiredRuntime version="v4.0.30319" />
</startup>
This will work when form or server calling. But my COM may be called by vbs like:
Dim obj
Set obj = CreateObject("ClassLib.Class1")
msgbox obj.add(3,5)
In this case, I can't add that config file to the vb file. Is there any solution fot this?
I've got a project that's using SpecFlow, NUnit and Coypu to do acceptance tests on a web application. I've got the project building OK via Jenkins on a build server. Jenkins calls a psake script which runs msbuild on the specs project, then the script calls nunit-console to run the specs/tests, and then I want to generate a report from SpecFlow.
Framework "4.0"
task Default -depends RunSpecs
task BuildSpecs {
$env:EnableNuGetPackageRestore = "true"
msbuild /t:Rebuild ReturnsPortal.Specs.csproj
}
task RunSpecs -depends BuildSpecs {
exec { & "C:\path\to\NUnit 2.5.9\bin\net-2.0\nunit-console-x86.exe" /labels /out=TestResult.txt /xml=TestResult.xml .\bin\Debug\TheWebApp.Specs.dll }
exec { & "C:\path\to\SpecFlow\1.8.1\specflow.exe" nunitexecutionreport TheWebApp.Specs.csproj /out:SpecResult.html }
}
That last exec call to specflow.exe fails though, with:
The element <ParameterGroup> beneath element <UsingTask> is unrecognized. C:\Program Files (x86)\Jenkins\jobs\TheWebApp\workspace\Web\Sites\TheWebApp.nuget\nuget.targets
A bit of googling hints that maybe it's a problem with the msbuild version being used (e.g. here, here). But I have Framework "4.0" in my psake script, and the Specs project is targeting .NET Framework 4.0, and it builds fine in the build step, so I'm not sure why specflow seems to be using an earlier version of msbuild. Or is maybe the problem somewhere else?
This was the answer for me, from the SpecFlow Wiki:
Important for .NET 4.0 projects: Because specflow.exe is compiled for .NET 3.5, it cannot load .NET 4.0 assemblies by default. To generate this report for .NET 4.0 projects, you have to force specflow.exe to use the .NET 4.0 runtime by using the config file. Just copy the config below and create a specflow.exe.config file and put it next to your specflow.exe and you will be able to create the step definition report.
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<startup>
<supportedRuntime version="v4.0.30319" />
</startup>
</configuration>
I attempted to use the config file solution suggested above. It worked for testing locally, but as soon as I pushed my code to our CI environment it choked on it since the CI environment doesn't have that config file. We restrict out CI environment to only use clean versions of the various packages, so we didn't want to try to inject the special config into the CI server.
We noticed that SpecFlow works just fine with several of our .NET 4.0 projects without the special config file. After a little research, the actual 'problem' appears to be NuGet 2.1. Everything works fine for .NET 4.0 projects with NuGet 1.7.
Somewhere between 1.7 and 2.1 NuGet introduced new features in the NuGet.targets file that aren't supported by the older versions of MSBuild. Specifically the problem seems to be the <ParameterGroup> beneath element <UsingTask>, as explained by the error message.
A cursory glance at the targets file indicates that the section is responsible for keeping NuGet up to date. Removing this section completely resolves the issue in the same manner that adding the config file above does, albeit also removing the self-update functionality that is seems to provide. Given that the .targets file is committed to the repository, this solution also works on our CI environment with out any changes on the CI side.
It's not necessarily a better solution than ngm's, it's just a different one. Depending on your environment, this may be a preferable way to go, or perhaps not.
I am using the reportviewer control from VS 2010 to create client side reports (rdlc). Everything is working fine on my development machine, and when I manually compile (via VS2010) and manually deploy to a test machine that doesn't have development tools installed.
In order to get the test machine to work (without installing VS2010 or ReportViewer.exe), I had to add references in my project to Microsoft.ReportViewer.Winforms, Microsoft.ReportViewer.Common and Microsoft.ReportViewer.ProcessingModel and have them all "Copy Local".
I have the rdlc files configured for Build Action => embedded resources. This is the default setting when adding a new rdlc to the project. I am open to configuring this otherwise if this would resolve this problem (no idea if its related).
The problem: since adding the rdlc files, the solution no longer builds on the build server. I have installed ReportViewer.exe on the build server, and have verified that the required assemblies exist in the GAC. The .Net 4 framework is NOT installed on the build server--I don't think this is required because the solution targets the 3.5 runtime.
I believe the root of the problem is the following from the build log:
Target "RunRdlCompiler": Building
target "RunRdlCompiler" completely.
Output file
"obj\Release\RdlCompile.compiled" does
not exist. Using "RdlCompile" task
from assembly
"Microsoft.ReportViewer.Common,
Version=9.0.0.0, Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a". Task
"RdlCompile":
Report\RDLC\GreenReport.rdlc (0,0):
error rsInvalidReportDefinition: The
report definition is not valid.
Details: The report definition has an
invalid target namespace
'http://schemas.microsoft.com/sqlserver/reporting/2008/01/reportdefinition'
which cannot be upgraded.
From what I can tell, Microsoft.ReportViewer.Common version 10.0.0.0 is what should be used to "compile" the rdlc, but MSBuild appears to be using 9.0.0.0. I believe if I could force it to use the right version (which IS installed in the GAC), the solution would compile.
This is because your Microsoft.Common.Targets file is pointing to the 9.0 version of the assembly.
If you look in [sysdir]\Microsoft.NET\Framework\v3.5 you will find Microsoft.Common.targets, which is driving a lot of what MSBuild does. This verion of the common targets file points to [Program Files]\MSBuild\Microsoft\VisualStudio\v9.0\ReportingServices\Microsoft.ReportingServices.targets forcing MSBuild to run with the 9.0 version.
When you installed .NET 4.0, you got a new common targets file in the v4.0.x directory, this new one now points to [Program Files]\MSBuild\Microsoft\VisualStudio\v10.0\ReportingServices\Microsoft.ReportingServices.targets which points to the 10.0 version of the ReportViewer assemblies.
The 10.0 ReportViewer is compiled against .NET 3.5 and intended to work in both 3.5 and 4.0. You could very likely get rid of the .NET 4.0 framework, and alter your 3.5 common targets file to point to the new ReportingServices target file, and it should work. In theory anyway, I've never actually tried it. You may be best off just sticking with 4.0, as that's what we intended when we designed the MSBuild support for the new viewer.
Just install Microsoft Report Viewer 2010 SP1.
I had a very similar issue. Just all of a sudden I could no longer build a VS2010 project that contained an .rdlc file. I wasn't converting any reports or using a report server, everything was local. I tried creating a brand new project and adding an empty new rdlc report and hit build and it wouldn't work. Just one day it stopped compiling and gave me the following error:
The report definition is not valid. Details: The report definition has an invalid target namespace 'http://schemas.microsoft.com/sqlserver/reporting/2008/01/reportdefinition' which cannot be upgraded.
Turns out the issue was my "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\ReportingServices\Microsoft.ReportingServices.targets" file had somehow changed. The top of my file was:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.Common, Version=9.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
And it should have been:
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
I changed that one "Using Task" line in the file and everything builds again. REALLY frustrating and it ate up two days of my life. Hoping posting this comment may help someone else in a similar situation.
Jim Lafler
I have tried re-installing all and it didnt work. Then, I tried updating Microsoft.ReportingServices.targets as per Jim's post but even didnt work for me.
At the end, I just copied Microsoft.ReportingServices.targets from other machine (where it was running without error). And surprisingly, it is working.
The additional difference I noticed while comparing, to change PublicKeyToken along with Version.
This may be the case for me only but Jim's post was much useful.
SFUH
Turns out I did need the .Net 4.0 Framework, and more specifically the 4.x version of MSBuild, which uses the newer version of the Microsoft.ReportViewer.Common library.
So even if you are targeting the 3.5 framework, if you create the rdlc with VS2010 it will expect to be "compiled" using 4.0 tools.
I have the same problem: we using ReportViewer 2012 (version of assemblies starts with 11). Both on local machines and on build machine are installed ReportViewer 2012 package and VisualStudio 2013. On local machines compilation in VS succeeds, but on build machine during queued build MSBuild throws such error:
The report definition is not valid. Details: The report definition has an invalid target
namespace 'http://schemas.microsoft.com/sqlserver/reporting/2010/01/reportdefinition'
which cannot be upgraded.
I tried to modify Microsoft.Common.targets from .NET 3.5 folder in way, that is described in this post, but no effect. Then I opened Microsoft.Common.targets from .NET 4.0 folder, and found there such strings:
<!-- VS10 without SP1 and without VS11 will not have VisualStudioVersion set, so do
that here -->
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)'
==''">10.0</VisualStudioVersion>
</PropertyGroup>
Then I realized that problem may be in incorrect value of variable $(VisualStudioVersion), so I added to build definition in section "Process" this MSBuild parameter:
/p:VisualStudioVersion=12.0
And it worked! Build completed successfully.
Hope this will help someone.
Pasting file paths doesn't seem to be going through... how about this:
Was:
TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.Common, Version=8.0.0.0...
And is now:
TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0...
James
The NetFx40_LegacySecurityPolicy was enabled in my devenv.exe.config, and when I commented this line out, the project built successfully.
We had enabled the legacy security policy on our team to enable our team to work with DevExpress 7.2 controls from within Visual Studio 2010, but in this case, it shows that the approach we took is not always the best.
I lost 2 full days of development due to a similar issue. On building my project it would succeed, but on rebuild it failed with no errors. On investigating the verbose build log in the Output window it directed me towards a problem with the rdlcompile function (so reporting services local report embedding issue). After trying every thing I finally manage to resolve the issue, but disabling my virus scanner. The Antivirus was somehow interfering with my rebuild and caused the rebuild to fail.
After disabling virus scan, rebuild works 100%
I have same problem on my Visual Studio 2013.
The dll version of reporting service on my project is Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
When i checked my ReportingServices targets
C:\Program Files\MSBuild\Microsoft\VisualStudio\v12.0\ReportingServices\Microsoft.ReportingServices.targets
I found the task version is 11.0.0.0
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=11.0.0.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91"/>
When i changed the task version to 10.0.0.0 corresponding to dll version on my proejct.
<UsingTask TaskName="Microsoft.Reporting.RdlCompile" AssemblyName="Microsoft.ReportViewer.WebForms, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
It' worked.
I just removed this file from my file system. The reports are simply ambedded no need to be compiled.
c:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\V11.0\ReportingServices\Microsoft.ReportingServices.targets
this worked fine for me and for my build server.