I have an old MVC2 project, which I am trying to move from an old cruise control CI server to our current TeamCity CI Server.
I'm getting screeds of build errors of the form:
Models\State\ControllerStates.cs(3, 18): error CS0234: The type or
namespace name 'Mvc' does not exist in the namespace 'System.Web' (are
you missing an assembly reference?)
I get a lot of warnings of the form:
[14:57:16]ResolveAssemblyReference
[14:57:16]C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1360,
9): warning MSB3257: The primary reference
"System.Runtime.Serialization" could not be resolved because it has a
higher version "4.0.0.0" than exists in the current target framework.
The version found in the current target framework is "3.0.0.0".
The TeamCity build step is using the Visual Studio (.sln) runner vs2012
Here's part of the csc command logged by team city.
/reference:C:\Windows\Microsoft.NET\Framework\v4.0.30319\System.Configuration.dll et al.
I found a VS2012 installation it works correctly, and the similar parameter looks like this:
/reference:C:\Windows\Microsoft.NET\Framework\v2.0.50727\System.Configuration.dll et. al.
So it's using the wrong version of some assemblies, and I'm not sure why.
I have no idea what was wrong, but I've set up a new build agent and that works correctly, so I don't think TC or my project are to blame, but rather something fishy with the setup on the build agent.
This is not a great answer, but if you have a similar problem you may want to cut to the chase and re-build or add a new build agent.
Related
I am trying to set up a new TeamCity build job and am facing a build issue.
The build failed because of missing references within ResolveProjectReferences step.
For instance :
JSonTools\JSonHelper.cs(21, 7): error CS0246: The type or namespace name 'Newtonsoft' could not be found (are you missing a using directive or an assembly reference?)
Prior to the build step, 2 restore nuget steps are set up and both ran successfully (one for sdk like project and the second for previous version, in this order)
When I run my solution on the agent and restore nuget packages through VS it is working fine (and TC job will run successfully if made on the same agent)
I noticed the dlls pulled during the restore nuget steps are in the path of my sln, while it seems to be require on others path.
Several VCS are set for this job and from what i can see/understand, the failing projects seem to require the dll to be in their own path under the packages folder.
\this
\is
\my
\path
Project1.csproj
packages\ (<- contains all the Dlls)
\folder1
\Project2.csproj
\Project3.csproj
\packages\ (I have the feeling some Dlls should be here but the folder doesn't exist)
\folder2
\Project4.csproj
\packages\ (same as previously)
Did I missed something ?
Any help would be appreciated.
Thanks,
Cervelle
I have a .Net project using NUnit Testing built with Visual Studio 2019, which is working fine on local. But when I push the project to origin/master Github with Travis CI, it was giving me messages like:
The type or namespace name 'Point' does not exist in the namespace 'Triangle' (are you missing an assembly reference)? [/home/travis/build/phamhoangvu922/TriangleTesting/Triangle.Test/Triangle.Test.csproj]
I've worked through all of the issues such as making sure all the projects in the workspace are using the same version of .Net for the Target Framework setting etc but not works for me.
How can I fix it?
In my Blazor application, on the client side, IntelliSense complains about a lot of Microsoft.AspNetCore packages although the project compiles and runs fine.
I get a lot of things like
The type or namespace name 'Mvc' does not exist in the namespace 'Microsoft.AspNetCore' (are you missing an assembly reference?)
The type or namespace name 'Razor' does not exist in the namespace 'Microsoft.AspNetCore' (are you missing an assembly reference?)
...
Things like
#inject HttpClient Http
are also underlined with red squigglies.
The project builds and runs perfectly.
What is wrong here?
Followup 1
Because I was asked for all versions:
Visual Studio 2019, 16.0.2
Microsoft.AspNetCore.Blazor.Templates::3.0.0-preview4-19216-03
In my project:
Id Versions ProjectName
-- -------- -----------
Microsoft.AspNetCore.Blazor.Build {3.0.0-preview4-19216-03} MyBlazorApp.Client
Microsoft.AspNetCore.Blazor {3.0.0-preview4-19216-03} MyBlazorApp.Client
NETStandard.Library {2.0.3} MyBlazorApp.Client
You need Visual Studio Preview version 16.1 or higher to work with 3.0.0-preview4 Blazor.
If that alone doesn't help, verify that you dont have any .cshtml files in your client project - they all have a .razor extension since 3.0.0-preview4. The presence of .cshtml file triggers a different SDK's behavior, requiring AspNetCore.Mvc namespace. Though Microsoft guys see it as a bug and probably will fix it.
https://github.com/aspnet/AspNetCore/issues/9640
Shut down VS
Delete the .vs folder or the .suo file
Restart VS
uninstalling x86 version of .NET Core 3.0 Preview SDK
https://dotnet.microsoft.com/download/dotnet-core/3.0
Then installing the x64 again on Windows10 64bit fixed that issue for me
I am running into the weird issue that the script component of an SSIS package deployed as part of an ISPAC file fails if the project deployment is done in an automated fashion - from C# or using PowerShell, that is. Deploying the exact same project using the Integration Services Deployment Wizzard in Visual Studio does not raise any erros when executing the package on the server.
However, I am getting various errors about things missing in the system namespace when executing the package that has been deployed with C# (using Microsoft.SqlServer.Management.IntegrationServices) such as:
DFT Load STG_ETL_TEST_STAGING_CDC:Error: CS0234 - The type or
namespace name 'ComponentModel' does not exist in the namespace
'System' (are you missing an assembly reference?),
Properties\Resources.Designer.cs, 59, 25
DFT Load STG_ETL_TEST_STAGING_CDC:Error: CS0234 - The type or
namespace name 'CodeDom' does not exist in the namespace 'System' (are
you missing an assembly reference?), Properties\Resources.Designer.cs,
25, 21
I exported the deployed packages and compared their file sizes. I noticed that the ISPAC of the manually deployed project is slightly bigger than the one deployed programmatically. What is the Deployment Wizzard doing to the project that isn't happening during automated deployment?
To exclude that it has something to do with my C# code, I also tried the following PowerShell script from the Microsoft docs. However, it does use the same assembly as I use in my code (Microsoft.SqlServer.Management.IntegrationServices) and the deployed package has the same issues.
I should have mentioned that the project was generated with Biml. Turned out the issue was not related to the binaries but the ISPAC file created by the Biml compiler. Building the project again with VS (using devenv.com theproject.dtproj -build) solved the issue for me and allowed for programmatic deployment of the project.
I have been trying to get my solution to build in a CI configuration using Visual Studio Online and the hosted build controller.
I have created a folder in the root of my workspace with the required NUnit binaries as per these guidelines.
I have also referred to these previous questions where users had issues trying to accomplish the same thing:
Visual Studio Online CI Nunit Tests not found during build
What else is needed to get the Hosted Build Controller to run my NUnit tests
I have the "NUnit Test adapter for VS2012 and VS2013" package installed in all of my test projects.
The error messages in my build log are like this:
Tracking_works_when.cs (35): The type or namespace name 'TestAttribute' could not be found (are you missing a using directive or an assembly reference?)
The type 'TestAttribute' is one of several missing ones, including 'Test', 'TestFixture' and 'TestFixtureAttribute'.
There is also the following warning:
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1605): Could not resolve this reference. Could not locate the assembly "nunit.framework, Version=2.6.3.13283, Culture=neutral, PublicKeyToken=96d09a1eb7f44a77, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
The same warning is repeated for "nunit.core.interfaces" and "nunit.core".
Question:
What am I missing? Why are my NUnit binaries not being identified within the hosted build environment and my tests run automatically?