We have a large solution here, with several dozen projects. The only build configuration which has been maintained is the Debug. When switching to release, I get over 300 error messages, mainly:
"Error The type or namespace name 'XXX' does not exist in the namespace 'Microsoft' (are you missing an assembly reference?) C:\TFS\...\SomeClass.cs"
and a few
"Error Metadata file 'C:\TFS\...\some.dll' could not be found SomeProject"
Is there a way to take the debug configuration completely, and generate a working release one? Preferably automatically/script based, to be done by build server for each release? Most projects are C#, with one or two in C++ or Managed C++ (these dont throw errors).
Could it be that those errors are coming from not building all the projects in the Release configuration?
Check this trough the Configuration Manager and see if all projects are selected to build for the Release configuration.
You can also create a new configuration and then select a configuration to inherit the settings from. Maybe you can create a copy of your debug configuration this way?
For automating a build, you can always use a combination of Powershell and MSBuild to script your build. If you have Team Foundation Server you can use TFS automated builds and publish them to a specified location.
Related
I have inherited a large LOB application that is built using TypeScript. The project has no reference paths in any of the files due to the fact it has been setup and created using Visual Studio 2013 - Visual Studio seems to have some magic where it will pick up the global TypeMaps itself. scoff.
The current build process has been to use Grunt to copy the compiled .js files (which are generated on save in Visual Studio) to a build directory - not actually compile them.
(to further reinforce this point, Grunt is NOT compiling any TypeScript).
This build process is now no longer acceptable as I am moving the application to a build through a Continuous Integration process, using Team City and Command Line tsc.exe/Grunt - so when the repository is checked out there are obviously no generated .js files in the project.
In its current state there is a host of compilation errors when trying to use Command Line tsc.exe/Grunt to compile the TypeScript files, I think due to the fact that the application is not using reference paths?
Does this mean I'm going to need to add all of the relevant reference paths to each file in the project?
Has anyone got any experience regarding this kind of setup and could point me in the right direction to manage these reference paths and build process?
Thanks
In its current state there is a host of compilation errors when trying to use Command Line tsc.exe/Grunt to compile the TypeScript files, I think due to the fact that the application is not using reference paths
No. You should use a tsconfig.json which will create the compilation context.
More
https://basarat.gitbooks.io/typescript/content/docs/project/project.html
A solution has been found.
Using the Visual Studio configuration options in the grunt-ts task I have setup the task to specifically use the projects .csprog and TypeScript 1.4 compiler (we are locked into this compiler).
My configuration for the grunt-ts task:
ts: {
default: {
vs: "Consortium.Client.Web.csproj",
options: {
compiler: "1.4/tsc"
}
}
}
I hope on the off chance, this helps someone else.
I have a multi-project solution. In fact, some projects happen to be shared by 2 different solutions.
Anyhow, one of these is a test project and uses RhinoMocks. I used NUGET to add this to the project, and the solution is set to enable the download any packages from NUGET.
It builds just fine when in DEBUG mode, but when I put it into RELEASE mode, I get:
Error 1 The type or namespace name 'Rhino' could not be found (are you missing a using directive or an assembly reference?)
I don't think it's limited to RhinoMock, I've occassionally got it with NUNIT too.
Any ideas here?
Thanks
I am using Visual Studio Team Services as source control and have enabled continuous integration.
My project is an ASP.NET application which used Entity Framework 5. When i checkin the code and the build controller tries to build it, the following errors come up
DataModel\GenomicsTutorDataModel.Context.cs (40): The type or
namespace name 'DbSet' could not be found (are you missing a using
directive or an assembly reference?)
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets
(1578): Could not resolve this reference. Could not locate the
assembly "EntityFramework". Check to make sure the assembly exists on
disk. If this reference is required by your code, you may get
compilation errors.
In my solution i have made system.data.entity CopyLocal = True yet no success.
Any ideas?
May be you are on a 64 bits machine and the TFS server is not?
Try to build your project for Any CPU or x86.
Add the DLL you referenced for System.Data.Entity into a folder in your project or somewhere in a folder in the Source Control and reference to that one. Check this in and try to build your application again.
I've just encountered a compile error I've not seen before. In a solution that contains Windows Workflow Foundation 3 projects, Visual Studio reports that it failed to compile the projects because it couldn't find an application-specific configuration file. The configuration file is NOT added to any of the projects. It is looked for only at runtime by the workflows. Other solutions using the same runtime config file compile without error. If I put the config file in the expected location then the workflow solution compiles without error.
The behavior suggests that when VS2010 is compiling WF3 projects that it is actually running the activities contained in the project at some point during the compile. Does VS actually run activities in WF projects during compile? Does it create activities? If it doesn't, why would the compile error be thrown for a file that isn't part of the project?
Actually I believe it suggests you have a compile time dependency on the config file in question on this one solution that you do not have in the others you mentioned.
Check if the error provides any details as to WHERE it has this compile time dependency and remove it if it is not needed. If there is nothing informing you or hinting where this may be, start digging into the various project properties in question and see if you have a build dependency on the config file.
I have a solution with a SQL CLR project in VS2008. The solution / project was converted to VS2010 and now the deploy no longer works.
I get the following type of erros:
Beginning deployment of assembly MyProjectDatabaseCode.dll to server DEVPN-004 : MyProject
The following error might appear if you deploy a SQL CLR project that was built for a version of the .NET Framework that is incompatible with the target instance of SQL Server: "Deploy error SQL01268: CREATE ASSEMBLY for assembly failed because assembly failed verification". To resolve this issue, open the properties for the project, and change the .NET Framework version.
C:\inetpub\wwwroot\VS2010_MyProjectSolution\DatabaseCode\bin\Release\MyProjectDatabaseCode.dll : Deploy error : Plan verification encountered errors; deployment cannot continue.
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\TeamData\Microsoft.Data.Schema.SqlClr.targets(96,5): Deploy error TSD00561: This deployment may encounter errors during execution because changes to [dbo].[Column1] are blocked by [dbo].[Table1].[Column1]'s dependency in the target database.
I verified and the project is targeted against .NET 3.5. We have predeployscript.sql and postdeployscript.sql files that are supposed to be run. It appears like they are not being run by VS2010. What could be causing the issue?
We ended up contacting Microsoft and they reproduced our issue as a known bug. They offered a workaround by retargeting the assembly to .NET 2.0, but that didn't work in our scenario either.
It seems that the only way forward until the fix is to create a brand new SQL CLR project in 2010 and add all the files to it by hand.
I'd recommend using Reflector to take a look at your assembly in the build output directory. If you see 2 references to mscorlib, then what has happened is that a phantom reference to the 4.0 framework has been added to the project. If you see this problem, you may be able to get rid of the 4.0 reference by hand editing your project file. Open the project in an XML editor, and look for the following line:
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="2.0">
Change ToolsVersion="2.0" to ToolsVersion="4.0"
This helped me with a similar upgrade problem, but your mileage may vary. If you don't see the phantom mscorlib reference, you probably have another issue.
I've seem this problem consistently when I renamed some objects or somehow the target database got out of sync, that is, some objects were not dropped and Deploy was trying to recreate them.
I managed to fix it by running a cleanup script (drop objects/assemblies) from MS Server Management Studio and verifying that no old objects remained in the Database.
It's a try/error experience but you can try first to deploy to another server/database and if it succeeds, chances are you have some garbage in the target database, that's how I came to the conclusion for I was able to deploy to another database.