I check in a project that builds & runs fine on one computer, and then "Get Latest Version" from another. When I build & run on the second computer, I get errors like:
Could not load file or assembly 'System.Web.Cors, Version=5.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The system cannot find the file specified.
I've fixed this once by removing & adding back all references, but I can't be doing this every time I change setups. Why is it not pulling a complete project definition from version control?
If I delete all the files and download from TFS from scratch, on build the packages don't restore. If I run Update-Package, then I get the error: The given key was not present in the dictionary. Not sure what's causing that.
Update
Here's an example of the issue: I have Newtonsoft included via nuget, and it appears in the References list, but I'm being told it Cannot resolve symbol Newtonsoft, as per image below.
If you work with one XAML build definition, there are some steps (described here) you need to follow in order to have these NuGet packages restored during the VSO (TFS) build process.
Add following items to the solution. (Content of the nuget.config and .tfignore file can be found here)
Add one build.proj file under the root path of the solution folder. (Content of the build.proj file can be found here)
Create one folder named tools under the root path of the solution folder. Create NuGet sub-folder under tools folder, download and save nuget.exe under tools\NuGet path.
Check in nuget.config, .tfignore, build.proj and tools\NuGet\nuget.exe into TFS version control.
Modify the build definition to choose to build the build.proj file.
Then you will have NuGet packages restored successfully during the TFS build process.
Related
An ASP.NET (not Core) project.
Certain files, such as NLog.config, are set to Copy if newer (as per NLog documentation).
And if I click Build this works: NLog.config is only copied to the build directory if it is newer than the version that already is in the build directory.
However, if I click Publish, then NLog.config is copied to the publish directory no matter what, overwriting the version that is already there. (I'm publishing to file system).
It would be really helpful if the version that already is in the publish directory took precedence.
Note that NLog.config is likely to contain settings that are specific to the environment the app is published to and cannot be set in the app's source code nor pushed to git.
There is an option to make Publish not delete files already present if it can't overwrite them with anything - so if I remove NLog.config from source code and only keep it in the publish (and build) directories, things will work as expected. However, I cannot do so: I was explicitly asked to make Publish place a default version of NLog.config that only logs to a file if there is no such version in the publish location yet.
Is there any remedy here? Is there any way to force Publish not to overwrite NLog.config if it already exists in target location or at least not overwrite it if it's newer?
Maybe you can try and fiddle with CopyToPublishDirectory that can have the values Always, PreserveNewest, Never:
<None Include="nlog.config">
<CopyToOutputDirectory>PreserveNewest</CopyToOutputDirectory>
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</None>
I'm using a nuget package (let's call it A) which has dependency to another package, let's call it B.
To include A in my project, I changed .csproj file to:
<ItemGroup>
<PackageReference Include="A" Version="2.0.5" />
</ItemGroup>
When I run nuget restore package B is consumed from some nuget source too.
I want to replace dlls of package B with my own DLLs, I've created myself.
I can do it on my local machine by just copy pasting the desired dlls in bin folder. But how can I do the same on Azure Websites? Is there anyway to automate this process?
Is there any way to tell nuget not to fetch DLLs of B from nuget source and instead use my desired ones?
Update:
Thanks to Shahryar's contribution, we can also choose to add the dll file and set it to be copied to the compilation folder for implementation (define properties in the .csproj file).
In fact, it is mainly to change the content of final compiled files, because after the final deployment, it runs according to the compiled files.
Original Answer:
You can compile the web app locally first, and then replace your dll file with the corresponding file in bin. Use zip to package the entire compiled file, and then use zip deployment to directly upload the final compiled file to Azure (the operation of the web app deployed to Azure depends on the file uploaded in this way)
Have a look of Zip Deploy.
I'm currently trying to migrate an old ASP.NET WebSite project to Visual Studio 2015. I'd like to use NPM/Gulp to automatically compile LESS files to CSS (this task was done by WebEssentials in VS 2013).
I added a package.json file to the project to load the required components. This creates a node_modules folder in the root of the WebSite project, and this is where my problem starts:
Since WebSite projects don't have a project file, all files (and sub-directories) found in the project root folder, are automatically part of the project. Due to the deeply nested directory structure inside node_modules, this leads to errors because of too long path names.
An easy workaround is to set the hidden attribute on the node_modules folder (but this has to be done manually by each developer).
Is there a way to tell NPM to put the node modules into another directory e.g. one level above the project (..\node_modules) where the solution file is?
Or is it possible to set the hidden attribute on a folder from a gulp-task (which runs when the project is loaded)?
Based on #Rik's answer, I was able to solve the problem:
Instead of adding the package.json and gulpfile.js into the WebSite project, I added them at the solution level (as solution items). This means, that the node_modules folder is now in the solution directory at the same level as the WebSite project(s).
The only other change was to modify the paths in gulpfile.js accordingly.
You might want to check out npm 3.0+. It installs the modules in a maximally flat structure. It should reduce the paths lengths in the module directory.
From the release notes
Flat, flat, flat!
Your dependencies will now be installed maximally flat. Insofar as is
possible, all of your dependencies, and their dependencies, and THEIR
dependencies will be installed in your project's node_modules folder
with no nesting. You'll only see modules nested underneath one another
when two (or more) modules have conflicting dependencies.
#3697 This will hopefully eliminate most cases where windows users ended up with paths that were too long for Explorer and other
standard tools to deal with.
#6912 (#4761 #4037) This also means that your installs will be deduped from the start.
#5827 This deduping even extends to git deps.
#6936 (#5698) Various commands are dedupe aware now.
This has some implications for the behavior of other commands:
npm uninstall removes any dependencies of the module that you specified that aren't required by any other module. Previously, it
would only remove those that happened to be installed under it,
resulting in left over cruft if you'd ever deduped.
npm ls now shows you your dependency tree organized around what requires what, rather than where those modules are on disk.
#6937 npm dedupe now flattens the tree in addition to deduping.
https://github.com/npm/npm/releases/tag/v3.0.0
For upgrading the windows installation check out this package npm-windows-upgrade
unable to update auto-refresh reference 'ajaxcontroltoolkit.dll and
commonlogging.dll
I am getting this warning every time I build the project but the project is running fine without breaks in local system but I am getting error page in godaddy after uploading to server. is this the reason for 500 error in godaddy shared hosting server?
I had this same problem with the AjaxControlToolkit. I've got no idea what caused it, but by simply re-installing the toolkit into my project with NuGet, that fixed it.
Install the package by following the steps below:
Right-click on your project and select Manage NuGet Packages.
Search the online repository for the package you want. In my case, this was 'ajaxcontroltoolkit'.
Find the package in the list of results that appears and click the Install button on it.
What this does is it removes all previous references of the package (older DLLs and references in your web.config file) and replaces them with newer, correct references
It's that simple.
Hope this helps you
Look in the bin folder of the project - for a file called - in your case:
ajaxcontroltoolkit.dll.refresh
This will have an incorrect path to the dll file. You need to update the path to wherever the dll is now.
Had this same issue and manually creating a .refresh file for its DLL helped. Once I figured the origin of the relative path is the solution folder, and put that in the .refresh, everything worked for this and other references.
I hope this helps somebody...
Im using VS2017 and had an ASP project with 28 Warnings:
Unable to update auto-refresh reference 'XXXXX.dll'. Cannot find
assembly 'F:\Program Files (x86)\Microsoft Web Tools\Packages\…
...well...that directory had been removed!
To make matters worse (or better) when I create a new ASP project the references are handled a little different in solution explorer...and the assemblies referenced in the new project are in C:\Program Files (x86)\Microsoft Visual Studio\Shared
To fix my warnings...I edited the .refresh file.
You can do this by: 1: Double clicking the warning. 2: Navigate to it
in solution explorer under the Bin folder.
And changed (example)
..\..\..\..\..\..\..\Program Files (x86)\Microsoft Web Tools\Packages\AspNet.ScriptManager.bootstrap.3.0.0\lib\net45\AspNet.ScriptManager.bootstrap.dll
to
C:\Program Files (x86)\Microsoft Visual Studio\Shared\Packages\AspNet.ScriptManager.bootstrap.3.0.0\lib\net45\AspNet.ScriptManager.bootstrap.dll
I had the same issue / what solved it for me was simply to do a "Refresh folder" on the Bin folder.
I have created an application that compiles and runs like a charm on OS-X. I would now like to start getting it to work on Windows. To start, I copied the project to a windows machine and just tried to compile, but got this error:
:: warning: Qmake does not support build directories below the source directory.
Any ideas?
Set the shadow build directory to some folder on the same level of your project directory:
folder/
project/
project-shadow-build-release/
project-shadow-build-debug/
You can do this in the "Projects" view, via the toolbar on the left. To me, this warning was just an annoyance, a project never failed to build because of it.
Don't copy your project.pro.user file when you are copying a project from one machine to another, or from one directory to another. When you open the project, Qt Creator will offer to create a new build directory in the proper place.
Andref gave the correct answer to resolve this warning, but you may want to understand why this requirement exists.
In fact, the build directory must be at the same folder level as the project (i.e. it can't be above or below). The reason why is that the linker is called from the build directory. Hence, any relative paths to library files will be different than what you entered in your project file.
It kinda sucks. I like to put all intermediate files in their own folder. But you simply can't with qmake.
.pro.user are generated files by Qt Creator. They are unrelated to qmake and should not be touched (and not put into a VCS for that matter)
Just remove the files with the pro.user extension , worked for me
I also got this, trying to compile a project created on linux.
Another way to solve it is to change the paths in the .pro.user file (in the directory of your project)
Right Click on a project: Set As Active Project
Click on the Projects button (The one with the spanner image)
Edit build configuration : Debug / Profile / Release / and change the default directories, OR just uncheck the Shadow build check box.
The Build directory path should now change to black, from red