I have a solution file created with Visual Studio 2013. In it, I have a WCF project which contains some classes, and a Web Application project that calls some functions from WCF file. The web Application is able to reach it from codebehind of .aspx pages.
I have no issue building and compiling the WCF project. However, Visual Studio is unable to identify their classes.
In Web Application project, It underlines the using statement of the WCF class library in red, shows "Type or namespace could not be found" error. It takes the class from the file created by WCF automatically by Visual Studio.
WCF project is doing the same inside too. The two classes are in the same namespace, in fact, literally in same file together. Yet they can't see each other.
Long story short: I have 2 different projects in the same solution, they work and compile very well, but Visual Studio is unable to identify some of the classes in intellisense, even suggests to create new class. What would cause this?
EDIT: I removed the project from TFS, and the classes are colored properly, and so is the intellisense. Perhaps some files are locked as checked in, and causes trouble?
Usually we do not suggest adding the BIN and the OBJ folders to source control, but do add the 3rd party dll's or using nuget package to handle them. Basically all that you need as input for your application is in source control, but the output of you application (the created dll's, pdb's etc) should not be included.
If you insist on this, first please double check you have add all related dlls in source control(check in them).
Then if your local build is successful and just the TFS build is failing
then it is usually due to dll reference path issue. Make sure that the
Dll is referenced as a relative path in the project file (.csproj).
Also give a try with adding the dll files into the bin folder where the builds located in TFS server. That .dll needs to be on whatever machine(build server) is running the build and the build definition needs to be pointing at that location.
Please take a look at this similar question: Namespace could not be found - building using TFS
I unticked readonly option from my .sln file.
I opened my .sln file with notepad and removed all the "GlobalSection" properties. (Related with TFS)
This solved the problem.
Related
Currently through Azure Devops, I'm setting up a .Net Desktop type with pipe-line that includes assembly libraries. In my understanding this should've work if the scenario was TFS is on-premise and I can just install any 3rd party non-nuget libraries in that server and make the build work. Right now I was able to make this work by literally copying the .dlls but I felt its more of a hack than actually letting the build know that I'm referencing assembly / non-nuget package libraries.
I'm pretty sure i've missed something, is there a way to properly set this up?
Even though it's not a recommend way, but you could check in these libraries/dlls in source control. TFS could download them from server to your build agent and refer them.
First, make sure your local build is successful and if just the TFS build is failing then it is usually due to dll reference path issue. Make sure that the Dll is referenced as a relative path in the project file (.csproj).
To add a relative reference in a separate directory, such as C:\tfs_get\Sources\assembly\abc.dll, do the following:
Add the reference in Visual Studio by right clicking the project in Solution Explorer and selecting Add Reference.
Find the *.csproj where this reference exist and open it in a text editor. Lets say your .csproj location is c:\tfs_get\sources\myfolder\myproject\myproj.csproj
Edit the < HintPath > to be equal to
..\\..\assembly\abc.dll
This build will work properly with the assumption that the folders ( assembly, myfolder) under the sources folder exist in TFS.
Update
Have a folder named "libs", or "libraries", for example, that contains all the assemblies required by your projects to compile and run.
Reference these assembly by right click the reference folder of project and browser to these assemblies files.
For build, in Source Settings (XAML, Build Agent Folder)/Repository, keep the similar structure.
More details please take a look at this similar question : How to properly check in DLLs/assemblies to TFS/Visual Studio Team Services (was VSO)
I have a WebAPI project in Visual Studio 2013. If I build the project in Visual Studio, in the bin/ directory I see a file called MyProject.dll.config, which represents the web.config file at build time.
However, if I execute MSBuild from the command line, the .config file is missing, but all other files are present.
> msbuild.exe /t:build /v:q /p:Configuration=Debug /nologo \
D:\Workspace\MyProject\src\MyProject.sln
What gives? Why isn't the .config copied?
For deploying a web project or a web api project, the fact that there's no $(TargetName)$(TargetExt).config isn't a big deal. At run-time, IIS will use Web.config to figure out everything it needs for your assembly.
BUT!
If you're using a Web App or Web Api project as the basis for testing* then you can hit some snags. In particular, when it comes to assembly binding redirects (as is the case with something within the bowels of MVC which still relies on Newtonsoft.Json 4.5.0 when the current version at time of writing is 7.0.0). A colleague had a similar issue with another assembly his test project was depending on.
Now when you run your tests through Visual Studio (eg, via Resharper), they all work just fine. However, when your tests get to the CI server and they are run by nunit-console, you'll see assembly load errors. Not pretty. This is because of the described behaviour where VS is sneakily copying the .config file to the correct output and msbuild isn't. However, you can work around this with a post-build build event:
copy $(ProjectDir)Web.Config $(TargetDir)$(TargetName)$(TargetExt).config
This has resolved my issues with redirects. I hope it helps someone else.
You may ask "Why use a Web App or Web API project as your test project?". A Web* project is a lot more comfortable to deal with as a base for a test project which deals with .net assemblies and JavaScript tests as JavaScript is properly recognised (syntax highlighting) and there's a Scripts folder which has the quick "Add -> Javascript File" menu item for itself and descendant folders, so I prefer to use this instead of a plain Class Library project.
When I create a WebAPI project the web.config Copy to Output Directory is set to Do Not Copy by default. Did you select the Web.config in Solution Explorer and set this to a copy action?
I'm at a loss to explain why it seems to copy for you with the IDE build but NOT the msbuild cmd you show, this is not the behavior I see with a fresh WebAPI project in 2013.
I have several Visual Studio web application projects that include SVN externals. When a new file is added to an external module, VisualSVN brings it down to the file system, but doesn't add it to the Visual Studio project; it has to be manually added.
I might write a macro to automate this process, and I'm wondering if I can make it a one-step process by either:
Having the macro initiate the VisualSVN update, then do the work (Q: Is it possible to trigger a VisualSVN update from a macro?)
Hooking into a hypothetical "post-update" event from VisualSVN to fire a macro to do the work (Q: Does such an event exist?)
I assume you are currently working like this: your "external modules" are just a loose collection of source files without a project file. Whenever a source file is added, you update all your application project files by adding the new source file, so that it is compiled into all the application assemblies.
I think you are doing it wrong. Your project solution file should contain a reference to a separate visual studio project file for each external. Each source file should be compiled into exactly one assembly.
For example, you might have a C# library shared between multiple web applications. This library has its own .csproj project file, which lives in the external location. If a source file is added to the library, the .csproj is updated. The updated .csproj file is then pulled it via an svn:externals declaration when you update your project.
Can someone briefly explain to me the difference between Visual Studio's solution file (.sln) and project file (.vcproj).
It seems to me opening either one open the correct solution/project in Visual Studio. Is one the super-set of the other?
Note: I am currently using Visual Studio 2008 working on a project that was brought forward from Visual Studio 2005 (I believe).
A solution is a set of projects. If you need more than one project in your software, then go with solutions. I.E.: A Class Library Project + A Web Application Project.
A project file typically corresponds to a single module: EXE or DLL or LIB. A solution manages a collection of project files.
A solution is a collection of projects. Visual Studio is made so that it cannot function without a solution, so if you open a bare project, it will generate the solution automatically (or try to find one).
One solution can contain zero or more projects. Everything is in projects, so a solution with zero projects doesn't contain anything at all besides the solution properties.
Visual studio keeps track of where the projects are used, so if you open a project file, it will open (IIRC) the last solution where it was used.
When you create a project from scratch, a solution is also created, but it's not shown until you add another project to it. It looks like you have only the project open, but it's actually a solution containing the project that is open.
Specifically project files are intended to contain the data required to build the files in the project into an exe or dll. This file is utilized by the local compilers or with systems such as Team Foundation system and server side build agents.
Solutions are a client (IDE) construct designed to manage collections of projects, which in effect is a collection of different build definitions and associated files.
Solution files are typically made up of multiple project files.
(I know I am using Visual Source Safe, I do not have a choice because it comes with the MSDN Subscription license and my company does not want to buy a third party source control solution....)
I have a VS 2005 solution with 3 C# class library projects, 2 ASP.NET web site projects and one ASP.NET web service project that is stored in a Visual Source Safe database. Some of the projects reference a common library DLLs that handle common taskes.
When a new person sets ups the solution on their workstation and build it for the first time, it checks out the common library DLLs in the bin folder of the ASP.NET web site and web service projects. When another developer that is currently working on the project tries to build, they receive a "file excludely checked out by other user" message.
VS 2005 does not display the check mark next to the DLL that is causing the headache.
Is there a way to prevent this from happenning?
Why do you have the bin folder checked into SourceSafe? On projects I've worked on, the third party dlls were checked into a separate folder (maybe called ExternalLibraries or ThirdParty) at the same level as the solution file. The compile process would be set up to copy the dlls into the bin folder. This could be handled with .refresh files, or with a pre- or post-build step. This way, VisualStudio/SourceSafe won't see the files as having been updated, and won't try to check them out.
If the compile is already pulling the files in due to them being dependencies, I'd suggest removing the bin folder from VSS. This is not the same as an "Exclude folder from project" which hides the folder from VS05 when compiling (and gives you the compile error you mentioned.)
If the third party dlls aren't going to change, another option is to make those files read-only in VSS. This way, no users will be able to check out the files. (To mark the files read-only, you will need to change the permissions from the VSS management tool; the developer's tool doesn't have that feature.)
As for why it happens, I don't believe VSS checks the binary version numbers - it is only concerned with modify file date. If a new developer pulls all the code out, all files (including binaries) will have the current date as the modify date. This may be causing the unnecessary checkouts.
Regarding your later comments - I'm not sure why VS05 wouldn't see the files as under source control but the VSS UI does. I suspect it has to do with the .vss files (and similar) that are in that folder. In this case, VS05 is incorrect.
Not sure if this is the problem or the best fix, but if you update every developer's machine so that they have the same latest versions of the common DLLs installed, this shouldn't keep happening. I think VSS checks out the DLLs in the \bin folder if the version referenced by the project file doesn't match the version installed on the developer's machine.
#Pedro:
In the VS 2005 IDE inteface, it does not indicated that the \bin folder is in VSS. When I look at the project in the VSS UI, it shows that is checked out to the user who did the latest build on their workstation.
If I use the "Exclude folder from project" option, it will cause the compiler to throw "reference not found" errors.
In my solution structure, the class library project creates a reference to the third party DLLs using the "Add Reference" command. Then I set a project reference to the class librarys in my ASP,NET web site and web service projects (using the web site project template). Because the class library has a dependency on the third party DLLs, they are copyed in the \bin folder.
How do I set a file to read-only through the VSS UI?