I have a .NET Core console app and a .NET Standard library. The app consumes the library via a nuget source in RELEASE, and a project reference in DEBUG, via a Condition on each ItemGroup.
This is working great locally, as I can make changes and test both the library and the app in parallel. When the sources get committed (obviously the library before the app), the library gets published, and the app consumes the published package.
Now, this app is also one piece of a docker-compose, and I want to be able to debug while running in Docker. This is perfectly supported with Visual Studio, but it also means my app is built against the library package available in my nuget source, not a locally-compiled and debuggable one.
I do have clues as to how to work around this, but would like to know if I'm just not either missing something, or trying to reinvent the wheel (though I really like new wheels).
I could copy the library's sources and project as part of the Dockerfile, and make sure it respects the Condition within my app's csproj. This sounds patchy.
I could have a local folder within the app sources where I copy the freshly built library's .nupkg, which would be copied via Dockerfile before dotnet restore, and also mentioned in the Nuget.Config, but ignored in .gitignore.
I'm about to try #2. Is there a simpler approach?
Thanks.
Related
I am working through setting up our first build definition through TFS 2013. I have worked through all of the errors (mostly missing reference files) except one:
Type 'iDB2Command' is not defined.
The type is part of IBM.Data.DB2.iSeries.dll, which I have placed on the build server in the appropriate location. I am really at a loss as to what to do in this situation.
Obviously building through Visual Studio works just fine. The file is not registerable. The iSeries client/SDK installs are not necessary (I do not have them on my machine, and I can build).
My best guess is that it wants the .NET 2.0 SDK (TFS is running on Windows Server 2013 and I already had to install several versions of the Windows and .NET SDKs).
How do I get my build to see this file and complete?
Ultimately this appears to have been a permissions issue. By following advice similar to the answer to this question (which I had to do for the Excel reference), I needed to put the IBM DLL into a Libs folder within the Team Project.
Once I did this, and updated the references in the solution, the build worked just fine.
I've been working on a web application (ASP.NET 4.5 Web Forms), and then added it to TFS to make the source code accessible to the client. I had no trouble getting it added to TFS, but when I got latest on a different machine (than the one I developed on) to test if TFS was working, I'm running into a bunch of reference errors to basic things like EntityFramework, Microsoft.ScriptManager, System.Web.Optimization. A client has run into the same issue when he checked out.
The thing is, if I create a new web application project on this machine, it has all those same references, but they're working correctly.
I've seen suggestions to add the actual DLLs to the project in a /lib folder, then reference them instead, but I don't think that's the right course of action for these basic, built-in assemblies.
One more thing- when I publish to Azure, it works just fine.
Any clue how I can get these references working properly?
Full list of broken references:
- AspNet.ScriptManager.jQuery
- AspNet.ScriptManager.jQuery.IO.Combined
- EntityFramework
- Microsoft.AspNet.Membership.OpenAuth
- Microsoft.Aspnet.Web.Optimization.WebForms
- Microsofot.ScriptManager.MSAjax
- Microsoft.ScriptManager.WebForms
- System.Web.Optimization
EDIT: I finally got this figured out. Apparently even these key assemblies are generated into the "packages" folder where the project is located. I added this folder to source control and it worked fine.
Right click on one of the references (on your machine) select properties, then check the full path to where the assemblies are located.
If they are in a folder called packages under your solution then they are NuGet packages not built in assemblies. Which means you either need to check the packages folder into source control, or right click the solution and enable package restore mode.
If they are program files then they aren't really built in assemblies either, they're likely installed by something else you installed onto that machine.
I would like to activate continuous integration for a Prism application on a TFS build server. Actually the build controller is not able to compile the application because it does not have the Prism Library. Prism is registered in my Visual Studio on my developing machine and the project simply reference it. I was wondering if I should checkin the library within the project or should I install the library on the build server.
So what practice do you use to integrate application using dependencies on a build server?
In general, checking in the necessary Libs provides you with the advantage that setting up a new build controller requires less time.
We use a mixed approach on the matter:
- log4net, Rhino, NHibernate etc reside on a shared Dir within the source control
- Other packages that require setup and/or licensing (Infragistics, NCover etc) are installed on the build controller
I have only very basic knowledge on Prism, by 'Prism lib' do you actually mean the 5 Microsoft libraries
Microsoft.Practices.Composite.dll
Microsoft.Practices.Composite.Presentation.dll
Microsoft.Practices.Composite.UnityExtensions.dll
Microsoft.Practices.ServiceLocation.dll
Microsoft.Practices.Unity.Silverlight.dll
If yes, we would have placed them definitely within the source control
I finally opted for a solution based on pantelif idea.
Instead of manually checking in and managing depedencies manually, I used NuGet to reference packages. Firstly it is perfectly suitable for source control as it checks-out any file required to build the project. Secondly it supports easy updates of the libraries.
Thanks for your help.
I am building my deployment process and I am running into a really annoying problem.
Using Visual Studio 2010 Sp1 on a .Net4 project with ASP.NET MVC3 that I want to deploy to an IIS7.5 webserver. The deployment works fine - both from Visual Studio and command line - except for this one important part:
I am using NHibernate (with Fluent NH) in a class library that is referenced by my web app. These were installed using NuGet, and also show up on the server when deployed.
However, these depend on some other libraries:
Castle.Core
Iesi.Collections
NHibernate.ByteCode.Castle
These are also fetched by NuGet, they are referenced in my class library, and the references have "Copy Local" set to True. However, out of these three, only Iesi.Collections actually show up on the server!
Of course, I can copy them manually, but the next time I run the deploy, it will delete them. Deleting unused files is actually something I want, but these files should not be in that category!
What can I do to make Web Deploy respect the fact that these guys are desired members of my application!?
Try adding those assemblies as references to your web project otherwise implicit references in class libraries might not be included.
Have taken over the management of a system written in C# MVC. It's a pretty big project so working my way through it bit by bit to learn what everything does. I've just made my first set of changes to it, and am ready to deploy. To do this I changed the debug mode to production which has have all the correct settings for deployment on the server.
However, when I try to compile the project I get lots of Errors and warnings. Most are to do with the third party NLog library which is used in the project.
The type or namespace name 'NLog'
could not be found (are you missing a
using directive or an assembly
reference?)
I have double checked the using statements which are all okay, and in References there is a reference to NLog. In my handover guide for this project, it states that the NLog.dll should be within the bin folder in the project. Now, if I go into the folder structure of the project, I can see this bin folder which does contain NLog, and other objects that are throwing me errors. However, I cannot see this bin folder at all in the folder structure in Visual Studio, so I'm wondering is this my problem?
If anyone could offer any advice I'd be so grateful.
Thanks.
You shouldn't see the bin folder in the solution explorer, so that's not the problem. My suspicion is that NLog is included in a class library project that is required by some other project in the solution. For some reason, this class library project is not compiling and thus you have this library as well as NLog (which it brings along when it's compiled) not available. I'd make sure that you have NLog included as a reference directly in all projects which directly reference it or have a dependency that references it. Pay particular attention to any test projects, which won't typically get built when you build your production code using the right-click menu build action, but will when you build the entire solution.