I have created a build task in vs2012.
I ran it.
It complains that there are some missing references,
though I see them on my proj and they lead to relative path
(the folder that exists in the source control)
I have ereased the sln locally,
I did get latest from the source control and rebuilt it.
The references were missing. I have fixed it. Re-run the taks and again similar error.
How can it be if the sln builds successfuly on my machine and on a colleage clean machine?
If I had to take a guess, it would be one of the following:
The missing types are located in one or more assemblies that are either not checked into source control; or
Those assemblies are referenced via a path reference that isn't the right path in your source control.
Those assemblies aren't part of the normal project structure that would be pulled down by the build server.
Those assemblies are gac'd locally and you are referring to gac'd versions instead of the correct ones.
It's a web site project and someone on your team has those assemblies gac'd or installed in some other directory and they screw up the project every time they check it in. (common in web site projects, highly unusual in web application projects).
Related
I found several problems while using MsBuild from command line and I think they are all related. There are also separated threads for them. The problem occurs for MVC project, created in VS2013.
First - what is the problem.
My bin folder contains several "*.npl" files + some extra dlls
When project A references project B, which references some 3rd party dll, the dll is not present in the package (or at least not on the server after deploy), however log4net is also not referenced in project A, but only in project B, but it IS being copied to bin (and package).
Environment and settings
My run command is like this:
msbuild projectA.csproj /p:Configuration=Release /p:Platform=AnyCpu /p:VisualStudioVersion=12.0 /T:Build
My machine is running Win 8.1 with latest updates, VS2012 MSBuild(4.0.30319.33440) installed. Server runs Windows Server 2008 RC2 with installed VS2013 and slightly updated MSBuild(4.0.30319.34209).
How it behaves
On my local machine, when I run this command, the build runs OK. When I open the bin folder I can see my 3rd party dlls (including log4net) with no extra files. All was built ok.
When I run this command on server, the same bin folder is now missing my 3rd party dlls (but log4net is there!) and there are also some *.nlp files and mscorlib.dll. The build itself returns 9 warning, mostly this one:
There was a mismatch between the processor architecture of the project
being built "MSIL" and the processor architecture of the reference
"{Several_System_Dll_Are_There}", "AMD64".
And one warning complains about missing SDK. Important to note, that I can resolve these warnings and solving the problem number 1 above (npl files..) by appending this line to the command.
/p:FrameworkPathOverride="C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0"
Probably the wierdest thing is the fact, that log4net works ok, but my 3rd party dlls are not. I checked csproj files. ProjectA has no reference to log4net. Only projectB references it. And they are referenced exactly the same (I checked the csproj in notepad). Only two differences are, that log4net was installed using nuget and also, log4 net is configuret in projectA's web.config.
As I was searching trough internet, I found these issues in separated threads and solutions were usualy by adding some extra settings to projects, editing csproj, sln, registry, etc. I don't like these solutions. Especialy, when the build works perfectly on my local machine.
The question is - why the server need frameworkPath to be specified? And why it is still not copying some 3rd party dlls? Why log4net works? And most important - Why is it working on my local machine, but not on the server?
Update - solution of 2. problem
So, it looks like I have a solution for the number 2 problem. The third party dll was referenced in GAC. And based on this Include GAC Assemblies in Bin, it looks like that msbuild can't handle that. adding True to the reference itself (MSBuild doesn't copy references (DLL files) if using project dependencies in solution) was not helping. I finaly had to add the reference on the third party dll to the projectA as well and add the Private tag. Now it works.
This is more like a hot-fix than solution. I don't have time for this.. if someone find a really solid solution, that would be awesome! :-)
I'm using a mysql .NET Connector library (Mysql.Data) in my project. As far as I understand it, I only need to use the mysqldata.dll which is in the assemblies folder after the connector is installed. I'm going to be using the program on a computer that has .NET 2.0 but doesn't have the connector.
How do I add the .dll file to a project such that the dll is used internally - I hope that makes sense. If the program calls out to .NET to find it, (as it does) - the whole thing fails and errors out.
In Solution Explorer, under your project, expand References, select the MySql.Data assembly, view the Properties for the assembly, and change Copy Local to True. Now when you compile the project, MySql.Data.dll will be output to the bin directory.
(You will not embed one assembly into another. Instead, you deploy the MySql.Data.dll along with everything else in your build output which is required. This is simply known as adding a reference ... I don't think you really wanted to embed it.)
Getting following build error:
error X2230: the type 'ASA.Log.ServiceLogger.IASALog' is in assembly
'ASA.Log.ServiceLogger' that needs to be referenced
Here's the scenario:
1) Only fails to build when do a Build/Rebuild Solution in Visual Studio (I have run clean multiple times)
2) The .DLL doesn't seem to be in the GAC
3) This is a clean "build" machine, we are working on setting up automated builds. It compiles fine on developers machines.
4) When I click on the error, it doesn't take me anywhere. It doesn't specify the line of code or even the related project. I have a bunch of C# and BizTalk projects in the same solution. By scanning the code/text on disk, I think I know which project it is. But each C# project builds successfully when built by itself.
5) The DLL being referenced is from another internal group (i.e. I don't have the code and cannot build it). I copied a new version of the referenced DLL from another machine's GAC to the library from where I'm referencing it. One theory was that I had an out of date DLL, i.e. that the GAC on the dev machines was current, but the DLL being referenced was not.
So I'm stuck and don't know how to get the build to complete.
Meanwhile, I'll go try FusLogVw, but would rather not install extra junk on this build machine.
It looks like one of the assemblies that you reference in turn references ASA.Log.ServiceLogger.dll which is not available. You should be able to get this dependency from the group that shipped the assembly that depends on it.
Found it, I had felt sure that the error was in one of the C# projects, but in frustration, I started building each of the 12 or so BizTalk projects. Finally, I found another project that had a "GAC" reference, and changed it to a disk/library reference, and life is good.
Your build machine dos not contain this missing reference in the GAC (Point 2 in your question). It compiles fine on developers machines (point 3). My suggestion is to add missing reference into the GAC.
I used to add my ASP.NET dependencies added as a 'Reference' in my project, and also added them manually to the '/bin' folder. This seemed a bit redundant, as so I removed everything from the bin folder. The project compiled and runs, but VS2010 started to act funny now. It doesn't recognized a lot of my controls (eg. Telerik UI) and therefore a lot of HTML is underlined as an error. So is this because I really need to add my files as both dependencies and into /bin, or a different problem?
Try to make a complete rebuild for your sollution.
Select properties on the referenced assemblies and check "copy local". This will copy the files to the /bin folder on compile.
Assemblies installed in the GAC will not need to be copied to the bin folder though. If you plan to deploy your solution to another machine, consider what assemblies are on your development machines GAC but not on the live/deployed server (and then either install them to the GAC on the live server or have vs copy to the bin by selecting copy local)
during development of our application we use a branching structure and while we are developing another team is using earlier builds of our software to create content with it.
To facilitate easy swapping between builds and teams I was hoping to use empty Hintpaths in the content projects' csproj files so that they can use our GAC installed assemblies to build against and in the meantime add a reference path to the projects for our use during development and test cycles where we don't want any assemblies installed in the GAC.
However, it seems reference paths are not stored in the csproj file and thus don't get sourcecontrolled. Since there will be extensive branching it would be less than ideal to have to set all reference paths again when a developer pulls another branch from sourcecontrol.
I've been searching for a bit now and can't seem to find ways to do this. Anybody know of a way to force the reference path in and out of sourcecontrol?
We're talking Visual Studio 2008 and TFS 2008 here.
Cheers,
Anton.
Ok, I seem to be a little clearer in the head after a good night's sleep, took the logical step, namely investigate where exactly the information was stored and how. It turned out the information was stored in the .user file for the project in the project's folder and as it turens out this file contains mbsuild xml.
I then did what I wanted as follows:
Create the Reference path as I required it to facilitate both scenarios without any work.
Browse to the Project's .user file
Copy the PropertyGroup containing the ReferencePath
Paste the PropertyGroup in all the necessary Projects' .csproj xml.
Reload and build.
Done.
The references are stored in the *.csproj file. The nodes are ItemGroup/Reference...
Thomas
This is pretty simple--we do this in our shop.
First, in the Workspace (using Windows Explorer, browse to the Solution folder), create a folder. We name it "Referenced Assemblies". In here, drop all your DLLs.
Now, in the Solution, add a new folder to match the one created in Windows Explorer. Into that folder, add all the DLLs you just dropped in.
Finally, in each project, set up your references to use the DLLs that were added to the solution.
Now your project references DLLs that are part of the solution, so that when the build runs, it will grab the DLL from Source Control to generate the build.
Also, I'd recommend not using the GAC at all if you can avoid it. In my experience, reference behavior is strange. It seems references go first to the GAC, then to the DLL in the local folder, meaning that if the DLL is updated, the one in the GAC is used instead of the DLL in the local folder (which is likely the updated one).