Here's my setup. I have a classic .Net website, not web app. I have all my compiled objects in a self-hosted nuget repo. When I build in VS, it looks at my packages and copies the binaries to the bin folder but when I try and build in Azure DevOps it's not working. My Nugets restore just fine but I haven't hit on the right msbuild arguments to make it work. I know that .Net websites are not common these days. I found this (How to use NuGet packages with an ASP.NET Website on CI Server) which was a path I was considering (putting .refresh.dll files in source control) but it seems like there should be an easier way.
How do I get my nuget packages copied to bin during a build for a asp.net website (not web app)?
What you are considering (putting .refresh.dll files in source control) is the most appropriate way.
From here:
They are simple because if you view them in a text editor, you’ll see
they contain nothing more than the full path to the dll.
Turns out, these dll.refresh files are an exception to the rule, and
they should go into source control. Its the only way your web project
will know where its references live.
For building and package restore to work, you can keep the bin folder and any .refresh files. You can remove the other binaries from your version control system.
Hope this helps.
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)
Cross platform Xamarin Forms project in Visual Studio and Visual Studio for Mac. The project references Akavache. Akavache has a dependency of akavache.sqlite3. I have made a custom change to a DLL in the akavache.sqlite3 repo and built the DLL locally, and would prefer not to have to switch the whole Akavache package tree over to a custom build for all the Akavache dlls and dependencies. So essentially...would like to continue referencing the NuGet package like normal but "substitute" one DLL on the fly. Or something equivalent like that!
But it needs to be portable too. At first I used a post build copy command to overwrite the "standard" dll that gets put in the TargetDir. That works in the sense that it copies to TargetDir, but for Android copying the DLL into the TargetDir does no good. The DLL is already incorporated into the APK in the TargetDir instead. So it would need to happen some other way. Same basic issue if you used MSBuild instead of a post build command line.
Any thoughts?
FWIW, my current workaround is to copy the DLL over top of the cached NuGet package location. But the problem with this approach is anytime the cache would get cleared/updated it needs to be reapplied. That's also not an obvious step to do, or easily automated, when another developer want to get set up on their machine.
Any .nupkg files are just ZIP files with some metadata, so you can change at the contents. The NuGet Package Explorer should make it a little easier to view the contents.
The NuGet Gallery (e.g. https://www.nuget.org/) has a "Download" link on the left hand side, otherwise just install the package into an empty project and then take a peek.
I've noticed that octopack is including the Roslyn folder under the bin folder for my web deployment. What would be the preferred method for excluding this from the build without affecting development. I considered a post build event in only the "release" solution config to delete it but wondered if there was a better way (and it doesn't need to be specific to octopus).
This folder is added by the Microsoft.CodeDom.Providers.DotNetCompilerPlatform nuget package. If you want C#6 support in Asp.Net (.cshtml or .aspx) files it needs to be there, because the roslyn's csc.exe from that folder is used to compile your views.
In order to be able to remove it (not deploy it), you'd need to precompile your web application with aspnet_compiler.exe
I am deploying asp.net web site via Octopus deploy. In TFS build definition I specified PowerShell script which pack and push Nuget package. Everything working working well except one thing: bin folder is not included in Nuget package.
When I tried to manually packing my web site into Nuget package I noticed that bin folder is included.
I supposed that something happened in TFS build process and bin folder is lost. But I cannot figure out how to solve this.
Any advice?
It sounds like you are trying to build a Website rather than a Web Application. Websites are only supported for legacy and don't get any love in the tooling. You can:
1) manually create your website layout for packaging with a post-build PowerShell script.
2) upgrade from a Website to a Web Application project and feel the love.
To upgrade you can create a new Web Application project in VS and delete all the specifics, like aspx files or other overwrites. Then drop the left over files on top of the Website, and open it in your solution. You will have two entries, one for site and one for app. Fix up the web app errors and build...
(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?