I'm developing my ASP.NET 5 app using Visual Studio 2015. There is no problem at all since RC1 with working with multiple projects in one solution, and so on..
But for a few days I have to work with VS Code and I'm not sure how to solve missing classes problem. Let's say I have solution with project A and project B. They have it's own classes inside. In previous versions of ASP.NET all files have been referenced in .csproj file, but now, my .xproj files are nearly empty. There are no direct paths to files. And in my project A I've created new classes, they have all correct namespaces, project B has a reference to A (even my controller in project B uses classes from same A's namespace!), but there is a compiltion error which says that my classes cannot be found in project A :/
I thought that with VS Code I have to add some kind of references in project, to notify compiler about that new files,but I cannot find a correct place to do it. Any ideas?
You do this in the project.json file.
{
"dependencies": {
"ProjectA": "1.0.0-*"
}
}
You declare the dependency. If the source is available in the solution folder, it will find it and use it. If the source isn't available, it can pull down a NuGet package that matches the version number. The documentation I linked to above provides more information about this process.
Once you have a dependency registered, you can refer to the public classes in your project. You'll need to fully qualify the dependencies (use the full namespace) or add a using <namespace> directive at the top of your file.
Related
I have a project that depends on another project, how can I configure Jenkins to use the reference of that project in the workspace.
For an example, project B depends on a certain set of classes from project A. Jenkins should be aware to build project A first and then B.
The trigger point is when a commit is pushed to the master of project B.
If a project depends upon another project, it is typically part of the same solution and always part of the same source tree. This means the slave will probably have the source already - or if it doesn't, the step that obtains the source needs the workspace mapping updated to not exclude it.
Also, when a project depends upon another project, the reference information includes the path to the referenced project. In the absence of solution file, this is used directly to build the other project with the same configuration (as in Debug/Release).
It's usually best to use a solution file instead of building projects directly as that ensures platform/configuration customisation is honoured as well as determining the correct build order of the projects.
So I got it sorted out. Since my project was based on project reference, the path had to be the same.
Naming the Jenkins project folder same as the dependent project name I referenced solved the issue.
I was under the impression that another workspace can't access another workspace. But it seems to be Jenkins handles it internally when building projects.
Everything was rolling along smoothly until a few days ago when UWP all of a sudden stopped building after pulling a new version from VSTS (git) with the errors:
Cannot resolve Assembly or Windows Metadata file 'Type universe cannot resolve assembly: X.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.'
Could not copy the file "obj\x86\Debug\MainPage.xbf" because it was not found.
Could not copy the file "obj\x86\Debug\App.xbf" because it was not found.
Could not copy the file "obj\x86\Debug\X.Mobile.UWP.xr.xml" because it was not found.
I have a solution structure of the following:
X.Core (.NET Standard class library)
X.Mobile (.NET Standard PCL)
X.Mobile.UWP (UWP specific project)
UWP references Mobile, and Mobile references Core (Core is also referenced by a web API project).
The commit that I pulled from source control did not have any changes to the X.Mobile.UWP .csproj file.
Things I have tried:
The obligatory clean and rebuild.
Delete all obj and bin folders for the entire solution.
Remove and re-add all references in the .UWP project.
Upgrade Xamarin.Forms to the latest stable (3.1.0.637273).
Remove and re-add X.Core reference in the X.Mobile project.
Delete C:\Users\%username%.nuget folder.
Update Microsoft.NETCore.UniversalWindowsPlatform to the latest stable (6.1.5).
Change the target version to all available versions - we've been running on build 16299 for several months.
And I've been beating my head against this problem on and off for days now. Android and iOS projects build just fine, which is ironic considering UWP has been our most stable platform. Anyone have any insight?
EDIT:
After adding a reference to X.Core directly to the X.Mobile.UWP project, I can compile. This shouldn't be the answer though since UWP never directly references Core.
I found the solution.
I had the very same problem because I had added a new (.Net Standard 2.0 Class Library) project into my Xamarin.Forms solution.
In short, initially my solution included the following projects:
BackgroundTaskTest (which have all my Views and ViewModels)
BackgroundTaskTest.Android
BackgroundTaskTest.iOS
BackgroundTaskTest.UWP
Suddenly I decided to add a class library named "BackgroundTaskTest.Common" in the same solution folder:
BackgroundTaskTest.Common (new one)
BackgroundTaskTest (which have all my Views and ViewModels)
BackgroundTaskTest.Android
BackgroundTaskTest.iOS
BackgroundTaskTest.UWP
The Android was working fine with it but the UWP project didn't like that new neighbor (which in your case is named "X.Core"). So I moved my classes from that new project to the "BackgroundTaskTest" again and deleted "BackgroundTaskTest.Common" from my solution with all the references and it has started working.
To finalize and make it short, please compare your X.Mobile.csproj file with X.Mobile.Core.csproj file. you will find the issue in the differences. Plus try to check all your dependencies to the X.Core project to make sure they are the same.
I installed NuGet package "NETStandard.Library" and added a reference to all my .Net Standard libraries to my UWP project. This solved the problem for me!
I created a new asp.net project, and I am using the monodevelop as the ide.
On the left hand side in the explorer I can see two sections, one is called reference and the other called packages.
I assume that references are the library or dependency files like the jar equivalent of java. Then what are the packages section for?
Is it also another kind of dependency?
Can anybody help me understand the meaning of those two sections?
I assume you mean References and Packages. There is no Resources section/folder when I create an ASP.NET project in MonoDevelop.
The References folder will show the assemblies that are being referenced by your project. An assembly is equivalent to a jar file.
The Packages folder shows you the NuGet packages that are being used by your project. A NuGet package will typically provide assemblies and these will be shown inside the References folder but within a From Packages folder. A NuGet package may include other things, such as content files, which are added to the project, or custom MSBuild targets which modify the build behaviour.
I noticed today that whenever I build a word add in project of mine, Microsoft.Sharepoint.dll is being copied into the bin folder and is subsequently included when publishing.
Is there an easy way to see why this (annoyingly large) dll is being included when publishing?
It isn't referenced directly. There are 3 dependencies in the project page and I've checked all these projects and none of them reference it directly either. Do I need to continue following the dependencies of those projects too?
Is there not some kind of log file for a build that could give me a hint?
EDIT:
The problem was that my project referenced a project that referenced a project that had a reference to Microsoft.SharePoint.dll with copy local set to true. I had to delete the dlls from all projects and rebuild with copy local set to false. I didnt realise that the 3rd party dll would be copied into my project.
If this is being pulled in due to a dependency from another DLL, then try looking at all of your DLLs in Dependency Walker. It finds all of the dependecies that a dll has. This is usually only when they are actually being used/bound, but you can also use the Fusion Log Viewer to see where all DLL binds are being bound from.
You could have a a look at reflection mechanism of asp.net or if not you could run trace using firebug for cross reference on browser ,
In an ASP.NET MVC3 project I have a structure like this:
Core.csproj
-> 3rdparty1.dll
-> 3rdpartyreference.dll
-> 3rdparty2.dll
Web.csproj
-> core.dll
I'm using the Build Deployment Package feature in VS2010. When I build, there are some references missing in the final bin directory. It only contains the web.dll, core.dll, 3rdparty1.dll and 3rdparty2.dll but is missing the 3rdpartyreference.dll.
How can I force the Deployment functionality to copy all the necessary references? (without manually creating a specific "copy something.dll" instruction in the afterbuild in the csproj)
The MSBuild tasks involved in the deployment package and publish features of VS 2010 fail to pickup indirect references by where your app depends on an assembly that depends on another. Either you can copy the files manually (not recommended), or you can add an unused reference variable to your core project that points to some class in the thirdpartyreference.dll. This reference variable, even if unused, will cause VS 2010 to think you have an explicit dependency on that third party dll and copy it to the bin directory as expected.
The feature you're looking for is called "Bin deployment". In this article there's a step-by-step solution. Basically, you need to add deployable assemblies to your project - specific folder will show up in your project structure where you can add necessary dll files.