I am using MSBUild to compile my solution. In my solution i have project "A". Project "A" internally call (projetc ref call) to project "B". But project "B" is not a part of my solution.
When i compile with MSBuild i am getting error "The type or namespace name 'XYZ' does not exist in the namespace 'Utilities' (are you missing an assembly reference?)"
When i compile in VS IDE (2008), I am able to compile the solution.
Solution
--> Project "A" (Part of solution)
-------> Project "B" (not a part of solution)
Thanks in advance.
Don't use solution references, use project references, and your build will work from both the solution and the command line. See this blog entry for an explanation of why solution dependencies are bad.
Related
ExcelRichTextHtmlUtility does not appear in the EPPlus 4.5.1 library (or 4.1 for that matter). I see it's in the code in source control but doesn't get shipped I guess. Is there a particular reason or maybe I'm doing something wrong.
It's in the source code but not compiled as part of the project anymore. When I include ExcelRichTextHtmlUtility.cs, the following line does not compile:
s = System.Web.HttpUtility.HtmlDecode(s);
In taking a look at the project settings, EPPlus targets the .NET 3.5 Client Profile framework. The Client Profile is a subset of the framework which for example does not include System.Web, so HttpUtility cannot be used so they must have just simply excluded the class.
I couldn't find any reference to exactly when and why this was changed so this probably does not completely answer your question.
Getting error
A reference to "file path\file.sln"could not be added. please make
sure that the file is accessible and that its is a valid assembly or
COM component
You mean adding a reference inside a project?
If is this, you can´t add a reference to a whole .sln, you will need to choose, for example, a valid .dll of the service you are trying to reference.
A reference to "file path\file.sln" could not be added.
That's a solution file.
[...] and that its is a valid assembly or COM component
A solution file is not an assembly or a COM component, hence the error. You need to add a reference to an actual assembly. If it's a project in your current solution, add a Project Reference. If it's not in your solution (and for whatever reason can't be added, though I highly recommend adding it if at all possible) then you'll need to add a reference to the compiled .dll of the referenced project.
You can't add references to solution files, project files, anything like that. Those are just XML metadata about projects. You need the compiled output, the assembly.
I created a new VB.net windows applications project and added a reference to my utilities project like I have done many times before. When I start coding, the editor will find the utility namespace without difficulty but when I build I get "Type My.Utils.Data is not defined".
I've compared my project to my other projects and can't find a difference.
When I try to debug, I get a dialog saying "Visual Studio cannot start debugging because the debug target "C:.....\myproject.exe" is missing
You need to make sure that the consuming project is targeting a .NET Framework version which is equal to or higher than the other project that it is referencing. If the referenced project is targeting a higher version of the framework, Visual Studio will not give you a useful message like, "Wrong Framework Version". Instead, it gives you a very confusing error about the assembly being missing, even though it's there.
I ran into this error and had a more unusual root cause. I'll add it here because someone may experience the same. (I don't expect this to be the "normal" cause of this error.) Anyway, I created a service reference and I removed the text "Reference" from the name of it and called it "ServiceName" rather than "ServiceNameReference. Apparently that created a naming conflict that blew up the reference.vb file.
I have a project where I have added a compile symbol (MYSYMBOL) in the project properties. When building from VS it works just fine and the application acts accordingly.
Other projects has various symbols defined this way.
When building from MSBUILD, MYSYBOL is for some strange reason ignored and the application acts as if it was never set.
I tried adding /p:"DefineConstants=MYSYMBOL" to the msbuild call, but then the build fails as it seems to replace the other symbols of each project with this one alone, so one assembly e.g. requires MYSYMBOL + OTHERSYMBOL but now only gets MYSYMBOL.
This is strange since it actually does use OTHERSYMBOL for those projects that have it, when building via msbuild.
Does anyone have a clue what could be causing MYSYMBOL on the project properties not to be used when building via msbuild?
Turned out that the build script has stated a set of compiler symbols on its own, overwriting the ones in the separate project settings which in turn caused this issue.
As far as I understand, you can't add one or more compiler symbols since anything you state replaced the symbols of the projects.
Ended up having to pass every symbol every project in the entire solution uses.
Too bad :(
You will want to add a new symbol to the list of DefineConstants (as opposed to overriding the entire list of DefineConstants). This will do what you want:
<PropertyGroup>
<DefineConstants>MYSYMBOL;$(DefineConstants)</DefineConstants>
</PropertyGroup>
I have a "Project A" that references System.Web.Mvc with CopyLocal=TRue.
System.Web.Mvc is in the GAC both on my local maching and on the buildserver.
I also have a "Project B" that references "Project A" in the output for "Project B" System.Web.Mvc is not copied to during the build.
I suspect that this is because it is in the GAC.
Is this true?
And can I do something to make MSBuild copy it to the output folder?
I read the answer from Muse VsExtensions in this thread, which talks about only the direct reference to the GAC, however we have an indirect reference through "Project A":
.NET Reference "Copy Local" True / False Being Set Based on Contents of GAC
This blogpost is also related:
http://deeperdesign.wordpress.com/2010/02/08/msbuild-assembly-dependencies-and-the-gac/
Did you check the .csproj file to verify that the reference does indeed contain the <Private>True</Private> tag? Copy local is unfortunately has 3 states in the xml - True, False and ... missing.
A pragmatic (read hack) solution is that I referenced System.Web.Mvc.dll in "Project B".
This is definitively not the right solution, so please bring me a better solution :-)
One suggestion I've seen floating around for this one is to change all of your projects to have the same output path. This is of limited value though, since if you have a dependency chain like:
Prj B > Prj A > Lib C
Then it's probably because Prj A is shared across multiple applications, for which you will want to each have their own output path.
I resolved the issue by instead using MSBuild to compile, and setting the OutDir property on each build.
e.g. MSBuild projectB.csproj /p:OutDir=C:\AppBOutput\
This will put the output for project B, its dependent projects (prj A), and prj As copy local dependencies all into the C:\AppBOutput\ directory.
Why it Works
When building the project in Visual Studio, both prj A and prj B have their own output directory, e.g. prjA\bin\debug and prjB\bin\debug. The GAC-stored assembly set to copylocal will be included in the output directory of the project that directly references it (prjA). But it will not be copied to the output directory of the project referencing that project (prjB). That's just how the project reference copying works. Dig into the MSBuild targets and I'm sure the underlying reason could be found (sorry, not doing it myself).
What the /p:OutDir=C:\AppBOutput\ MSBuild parameter does, is set the output directory of all projects to be the same. By doing this, you side-step the MSBuild behaviour of how it copies project-to-project reference outputs. Instead of relying on MSBuild to copy some of the content in prjA\bin\debug to prjB\bin\debug, you just force all projects to output to the same directory.