I'm making a build using FinalBuilder Pro 7.
I've an ASP.NET web site and I'm trying to use FinalBuilder's "Precompile Asp.net 2.0 Application" action. Well, It fails.
To build it successfully I need to run Visual Studio, open the web site and either build it manually from within VS or manually update all references. After that it works.
Now the question: How to force FinalBuilder to update those references? Even if I create web deployment project associated with the web site and try to build it with msbuild action it would fail for the same reason. Somehow neither action updates references automatically.
Update: OK. Maybe I need to force msbuild to update references. How to do that?
I found some properties that I can change at msbuild action.
On called ResolveAssemblyReferencesDependsOn I tried to put the value = true. Didn't help.
Any ideas?
There are different types of projects in .NET like library project, website project, web API project etc. As you mentioned in your question it is a website project, so I am going to give you a solution for website project.
You can build a project by two ways. Either you can build by visual studio or you can build by using MS Build. If you build your project by using VS, you can update references of your dependencies by executing the command "Update-Package -reinstall" in package manager console. It will reinstall all the packages automatically.
Please note that, all your dependencies are listed in packages.config file.
Secondly if you have to build your project by MS Build using cmd prompt, to load all the dependencies from nuget, you have to execute nuget.exe. By which all your dependencies will be loaded, but their references may not be updated. So in website project you do not have .proj file. So you can't have access to the references of your dependencies. Now problem is that how you can modify your dependencies references?
In website project reference of an assembly exists in its .refresh file. So you have to modify that .refresh file to update the reference of an assembly in website project.
Have you tried using the 'Build VS.NET Solution' or 'MSBuild Project' actions? Both should resolve your assembly references, provided the reference is set to the right location. This requires that you at least have a project file.
As I understand it, the Precompile action (which uses the MS aspnet_compile.exe - see http://msdn.microsoft.com/en-us/library/ms229863(VS.80).aspx) is designed to re-compile an asp.net application which has previously been built via VS or MSBuild. It does either an in-place compile to improve performance for the first user that hits the site, or creates a deployable application (removing source code etc). It's not meant as an alternative to VS/MSBuild.
I'm not 100% sure I understand the problem, but I believe you need to be able to correct some pathing on an assembly reference automatically.
I created a project to handle this (along with some other things): refswap.codeplex.com
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)
We're just in the process of transitioning from VS2013&15/TFS2013 to VS2017/TFS2017 (on-site TFS, not VSTS) and the first test solution is a dotNet Core 1.1 based one (a multi-project web service).
The solution builds fine on the original developer's box and I've got it out of TFS and it builds fine on mine too. In keeping with our previous methodology the contents of the packages folder are checked in with the projects as this makes the packages locally available on the build box (no internet).
Building the solution on the build server is a different story, however, as I get multiple errors of the form...
..\obj\project.assets.json' not found. Run a NuGet package restore to generate this file.
I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
This whole project.assets.json not found issue seems to be causing headaches all over. In my case the issue is that I'm trying to resolve it on our TFS 2017 Build Server, which does not and never will have internet access ('cos it's a server!).
All the solutions I've seen thus far seem to suggest running the Nuget Restore command but that can't work since the server cannot get to nuget.
This is nothing fancy yet, just a simple TFS 2017 Build definition with a Get sources and a Build solution step. I can't understand how something so simple has become so difficult.
Changing the Nuget Package Restore options makes no difference.
Since the project.assets.json files are generated on the fly in the obj folder, I can't even check them in to reuse. Can anyone please suggest a workaround, at the moment the test project is dead in the water.
Edit: trying the same process with a 4.6.1 web project created with VS2015 had similar results of unresolved references (e.g. System.Web) but didn't raise the same error, probably due to being an older, non-Core project.
According to I get the errors both when I run the TFS build definition and when I remote to the box and build directly through the VS on the box itself.
The issue seems not related to TFS build side since it also not work with local build through VS in the build agent machine.
Since this is a dotnet project. So, you could try to use “dotnet restore” and not “nuget restore”. Try using the dotnet core template (which uses dotnet restore).
If you are using authenticated nuget feeds, then you can use nuget restore but you also need to use nuget installer task. See https://github.com/Microsoft/vsts-tasks/issues/3762 for a discussion on that.
The Nuget version should be higher than 4.0.
Without dotnet restore and Nuget restore and only use get source/Visual Studio Build will not be able to build the dotnet core project. If your server do not have internet access, as a workaround you should use Local feeds.
We have a solution which contains several projects. Some projects have NuGet packages installed, for example Json.NET. The whole solution is checked in to TFS Version Control, without the packages folder. We have set up Automatic Package Restore according to the "Nuget 2.7+ method" as described in the Nuget documentation (actually we didn't set up that much since all this is enabled by default).
When we build this solution on another computer, all packages are getting restored.
When we build this solution on our TFS 2013 Build server, all packages are also getting restored.
Now here comes the problem:
When we create a build on our TFS 2013 Build Server which should build only one of the projects in the solution (so targeting the .csproj file instead of the .sln file) the nuget packages are NOT getting restored!
Can anyone tell me why this is happening, or tell me if this is by design? I really don't want to build the whole solution, since it is a release build for only a single small project, but i do want the packages getting restored automaticly...
I believe the Automatic Package Restore hooks into the Build Solution event. Since there's no solution, it's not triggering the restore.
To build a single project, you may need to create a new solution that references just that project.
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.
Normally "continuous package integration" involves source control, a build server, and participating teams fetching updated packages as often as they like. But I'm looking for a more extreme version of this story - without CM - that happens entirely on a developer's machine, all in one swoop. A more detailed description of what I want goes like this...
Using Visual Studio 2010 or 2012, assume a "foo.csproj" application that implements a plugin system. Each plugin represents a nuget package and has a corresponding Visual Studio project. Each of these projects is part of the same VS solution that contains the base application.
I want the following development story:
Change source code for a plugin.
Build solution, or perform a debug-launch, which causes msbuild to...
rebuild the changed plugin(s)
nuget then packages and uploads each plugin to a local repository (which can be just a subfolder of the VS solution)
rebuild the base application.
refresh the base application's nuget-plugin dependencies, which were just updated in prior steps. Notes:
This assumes MSBuild magically knows not to perform this last step until all plugins are built, packaged, and uploaded.
The "foo" application could itself use nuget.core to refresh the packages, but in this case I'm assuming that the VS build process did this step.
I would like to know if this story is common enough that there are "common" (msbuild?) scripts for this.
My own guess of how this should be handled is as follows:
All plugin projects are placed in a common "Plugins" folder somewhere in the VS solution folder structure.
The base application "project dependencies" are configured with references to all the plugin projects.
Note: I don't like the idea of managing these project dependencies manually.
The base application "foo.csproj" has a build step that scans the "foo.csproj" XML for dependencies it has in the "plugins" folder, and initiates the nuget packaging and deployment for each.
The base application then initiates the nuget "update all". Hopefully this is possible even though msbuild already mid-stride in execution.
In short, the base application is able to instantly consume plugins that have been altered. This is done without check-ins, a build-server, or manual and arbitrary requests to update plugin packages.
If pre-existing scripts do not already exist for this story, then I'll make my own. But I'd still like to know:
Can step 2, immediately above, be converted to something generic? That is, how can I convince msbuild not to build the "base application" until all projects in a particular folder have already been built? Remember, I'd like not to manage the project dependencies manually.
Is there anything flawed with this overall approach?
I would be particularly interested to know if there is an already existing nuget-visual-studio integration that assists with this story that I may have overlooked.
That's quite a long question to answer, so not sure I'm covering everything in this one; I'll do my best. First, your scenario is not uncommon. The first 2 steps of your planned approach seem OK to me (you're free to choose the location of the plug-in projects).
One thing's for sure: you'll have to manually define the build order, because your solution has no idea of knowing whether the projects consuming (NuGet) plug-ins have a dependency to the projects containing the source code for those plug-ins. Instead of using the built-in Build Order dialog in Visual Studio, take a look at this post on the MSDN blog for a correct way of doing this (or you might end up with something that works locally but not on the build server).
The key MSBuild elements in the referred post are the following:
<ProjectReference Include="... foo.csproj">
<ReferenceOutputAssembly>false</ReferenceOutputAssembly>
</ProjectReference>
Now, as for the packaging, deployment and consumption of those plug-ins:
Each plug-in project should trigger package creation and publication in a post-build step. This post on my blog contains ZIP-download with quite lot of MSBuild stuff you can use to get started. E.g. I version, package and publish the NuGet package for a class library in Release builds. I'm using the NuGet command line tool to pack (command reference) and push (command reference) the package.
The consuming application project(s) should run NuGet.exe update <packages.config> (command reference) in a pre-build step.
Also pay attention you're NOT running builds in parallel.