We have a .net core 3.1 solution, which we are able to compile (using Visual Studio 2019) and publish. We gave the solution to our team which is setting up the deployment process. While trying the build (linux container) they are seeing the below error:
CommonLib -> /srv/jenkins_work/DSS/ewcms/CMS/CommonLib/bin/release/netcoreapp3.1/CommonLib.dll
CSC : error CS8032: An instance of analyzer Microsoft.EntityFrameworkCore.InternalUsageDiagnosticAnalyzer cannot be created from /var/lib/jenkins/.nuget/packages/microsoft.entityframeworkcore.analyzers/5.0.9/analyzers/dotnet/cs/Microsoft.EntityFrameworkCore.Analyzers.dll : Could not load file or assembly 'Microsoft.CodeAnalysis, Version=3.7.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'. The system cannot find the file specified.. [/srv/jenkins_work/DSS/ewcms/CMS/Microsoft.EntityFrameworkCore.UnitOfWork/Microsoft.EntityFrameworkCore.UnitOfWork.csproj]
The file mentioned Microsoft.EntityFrameworkCore.Analyzers.dll is there in the folder mentioned in the error. other projects in the same solution have this as a warning, but this particular project shows it as an error.
Reading online many said to install Visual Studio, but that is something they said they can not do in the container, is there another way to get around this issue? Or something in particular we need to look at in that project which is causing and error rather than a warning?
After some investigation, turned out that project had the setting:
<TreatWarningsAsErrors>true</TreatWarningsAsErrors>
which was not there in the other projects, which were showing it as warnings only. Changed this to false and this project is also going through now, it comes up as a warning and allows the build to go through.
Related
Xamarin Android project is built well locally on Windows/Mac, but fails on AppCenter/Azure pipelines with weird errors like:
Error APT0000: resource style/Theme.AppCompat.Light.DarkActionBar (aka com.companyname.build_testing_andx:style/Theme.AppCompat.Light.DarkActionBar) not found.
Error APT0000: style attribute 'attr/colorPrimary (aka com.companyname.build_testing_andx:attr/colorPrimary)' not found.
This mostly looks like lack of necessary libraries to restore by Nuget.
As it appeared after long investigation, and no matter how the solution sounds dumb, but the solution might save some time for someone.
The reason such projects can't be build on AppCenter/Azure (and that might be related to any other Visual Studio project) is that Nuget packages not being restored successfully.
The problem is that when using Nuget task, it doesn't indicate any issues. It just finishes well.
But it happens because the sources don't include *.sln file, thus Nuget doesn't have a point where to start from for the packages restoring.
Sometimes it might happen when this file is just not included into sources pushed to repository by number of reasons.
*(It's weird because the builds often project-oriented, and when working on Visual Studio it automatically creates the .sln file (not necessary around the project folder), so sometimes it might just be not included and you have no idea what's causing the errors above).
So, just to be sure you've got your *.sln file added to your repository and it's available for the AppCenter/Azure build.
When I build my solution with a bunch of cloud projects, I see one or more "Error: Object reference not set to an instance of an object" messages in the output. When I try to run one of the cloud projects, I get the popup "There were build errors. Do you want to continue and run the last successful build", but there are no errors in the Error List and the same "Error: Object ref..." errors in the output.
When I click package on my cloud project I get a messagebox with "Object reference not set to an instance of an object", also when I right click -> properties on the project reference under "Roles" in the cloud project.
If I use the command line to build my solution with msbuild, I don't get the error.
I tried restarting Visual Studio as well as my PC. I also tried reinstalling Azure Tools (2.1) and then Visual Studio.
My colleague is now getting the same problem on Visual Studio 2013 RC.
Has anyone had the same problem?
I've searched, but only found people with problems when publishing, where the solution is to package manually.
I had the same problem. Right click on the cloud service project, unload the project. Reload it again.
Try removing the role from the cloud project, re-build solution (if there are errors please post them), then add the role back into the cloud project and re-build.
I had a similar issue when a publish exited out and I started receiving the 'Object not found' error. VS2013 (in my case) was reporting that 'diagnostics.wadcfg' was missing and had unusually stored this into a different directory.
By going into the project file (.ccproj) and removing the erroneous entry from the 'Project\ItemGroup\Content Include "\diagnostics.wadcfg" and reloading the project - everything kicked back into life.
Failing that, check a working project file against the offending project file for inconsistencies.
You don't have to remove your roles and add them back in again, which is really annoying because you have to preserve the contents of your cscfg and csdef files. Instead, close Visual Studio, delete the solution's .suo file and open the solution back up again.
I wanted to let everyone know I was dealing with a very similar situation, albeit with a different version of the Azure SDK (1.8). I have many projects with Cloud Services that I have created built numerous times and then all of sudden could no longer open them. Attempting to open the Cloud Service configuration UI resulted in the “Object not set to a reference” error. I could open the actual XML file, but not the GUI interface.
I attempted to reinstall the 1.8 SDK and tools numerous times, as well as VS 2012 to no avail. I finally tried installing the latest SDK (2.2) and now I can open the projects. Not sure what changed in my system prior to this but glad I was finally able to open my projects again!
I also had this error when building. Projects within the solution would build independently but building the entire solution failed.
I have learnt usually these types of issues are caused by invalid azure role or configuration files. In my case it turns out a .cscfg config file rename on another branch was merged with my branch but it didn't rename the file – therefore the .ccproj file in my branch was incorrectly referring to the new name but only the old filename existing in the solution. After manually editing the .ccproj with the new filename I closed/reopened the solution and things started working.
I had a similar issue with VS2013 express after creating a view in my MVC project.
I reverted the project with git, but this did not solve the issue. I also checked the project out to a different location on my pc, but this did not solve the issue. I was able to check the project out on my laptop without seeing this issue.
In the end, I undinstalled VS2013 express and all of it's counterparts and re-installed. This solved the issue.
I had this bug (but not using a cloud project). Turns out the character encoding that Perforce (P4V) was using was wrong, it should have been UTF-8. After changing to UTF-8 and re-syncing the code, Visual Studio was able to find and compile the project just fine.
Maybe a hint: I got the same error message, when compiling VS2013 Dot42 project - realized it was caused by assigning concrete value of some inner type (in my case Enum) to INullable variable:
private SomeClass.SomeEnum? _var1;
...
_var1 = SomeClass.SomeEnum.XY; // causes compilation error
The solution was, not to use INullable:
private SomeClass.SomeEnum _var1;
None of these answer helped me. I decided to reinstall the Azure tools, and noticed that I had more than one version installed. I uninstalled the old versions, reinstalled the latest version, and this fixed it for me.
I got the same message while publishing our project too, though in Visual Studio 2010.
For me, deleting all the files from bin folder worked.
I am trying to edit the build definition of one of my builds on Visual Studio (specifically, changing the password). As soon as I am finished and press Ctrl+S I get the following error:
Team Foundation Error
Could not load file or assembly 'Microsoft.Practices.EnterpriseLibrary.Common, Version=5.0.414.0, Culture=neutral, PublicKeyToken=31bf2856ad364e35' or one of its dependencies. The system cannot find the file specified.
I have looked into my build, dev and production servers and I can see the file and it is the correct version (5.0.414.0). Any idea what is going wrong here?
This was an issue entirely with Visual Studio on my local machine, not TFS.
Apparently when you edit a build definition, Team Explorer 2010 assumes you're doing it for your currently open solution. I still do not know why it could not find the assembly when it was clearly in my bin\Debug directory, but there you go.
The solution was a simple closing and re-opening Visual Studio. I was then able to edit and save the definition with the new parameter and promote to production appropriately.
Check if the assembly is included in your project and if it exist in the folder of your solution.
Sometimes when a person do a "Check In", but just some files the project dont know that the assembly must be included.
hope it helps.
I have an ASP.NET MVC project that loads fine when I start it directly. When I try to run it vai the Azure SDK's emulator, I get the following exception:
Could not load file or assembly 'file:///C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files\root\62253e0e\13ba4ff3\App_global.asax.a-wnopwm.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format.
This usually indicates something like a reference to a 64bit assembly on a 32bit system, but I've never seen this error on a ASP.NET project dll. The project configuration is set to AnyCPU. What gives?
The problem was due to the assemblyPostProcessorType attribute added to the system.web/compilation element of the web.config file when I used VS 2012's performance analysis (profiling) tool. It doesn't appear to clean up after itself very well and the config was left in place, causing an apparently assembly platform mismatch. It also caused problems when publishing to Windows Azure because the post-build assembly wasn't available.
The solution was to add a transform to the web config transform to remove the attribute (assemblyPostProcessorType).
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.