Develop Reference

Getting a list of all dependencies from a .NET Standard project's csproj

Ever since I've been using the (relatively) new .NET Standard Library project type in Visual Studio, I've been having some problems getting a complete set of DLL files that are required by my project.
The problem is usually limited to 3rd-party libraries which I reference as NuGet packages. I've noticed that these don't get copied to the output folder of my project when I build it. This didn't use to be the case in classic project types.
While I can appreciate the de-cluttering effect that this change has brought for .NET Standard projects, I'm now faced with a problem. I sometimes absolutely need to be able to get the entire list of all files that my project depends on!
I have several different cases, where I might require this list for one reason or another, but the one I believe is most crucial for me, is when I want to gather these files from the csproj itself, right after it's built. In there, I have a custom MSBuild <Target> which should take all the files from the output dir and zip them together for distribution. The problem is, I'm missing all the files that come from NuGet dependencies, because they're not there!
How can I solve this in a general (i.e. not project-specific) way?
UPDATE
There's this deps.json file that contains basically all I'm after and then some. It's just a matter of extracting the relevant information and find the files in the local NuGet cache. But that would involve writing a specialized app and calling it from my target. Before I start writing one myself... Is there something like this already out there somewhere?

I followed this answer and it sort of works.
The suggested thing was to include the following into my csproj:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
My main concern is that it also outputs some other DLLs from the framework (such as System.Memory.dll and System.Buffers.dll, among others), which I didn't expect. But maybe that's a good thing. They do seem to be dependencies, just not direct ones. I'll see how it plays out.
If it turns out ok, my only wish would be that this directive was more prominently displayed in project settings (as a simple checkbox, maybe?) so I wouldn't have to hunt the web to find it.

Make our copy of Source Code similar to the Compiled copy of code on Production Server

I have a project compiled and published on web server.
The copy of latest source code was lost. The copy I have right now is older one. There were alot of changes made after this copy of code.
How can I get my copy of Source Code up to date with the code on web server. The code on the web server is compiled and I have tried to decompile the code using-
Telerik JustDecompiler
DotPeek
RedGate .NET Reflector
When these applications decompile the code, the syntax is also changed.
What would you suggest the best way to merge my code?

Sadly, there's no way to get exact source code automagically, even from byte-code. At best, you'll lose all comments and readability. It could take a lot of efforts to restore codebase back to maintainable state.
Your best option is to generate source code from compiled assemblies using Export assembly source code function in Reflector or Export to project in dotPeek, and then compare the "old" and "decompiled" versions of files with diff tool (you'll either need source control enabled in VS or invoke diff manually, as suggested there).

Adding a VB file into a C# project

I am currently trying to add a VB file inside a C# project, but I am only able to add C# files. Is there a way for me to be able to add more language templates like what is shown below?
This picture below is an example of what I have been able to do in an old project which is to be able to add both VB and C# files into one project.
Update: I am redeveloping an ASP.NET 2.0 site to the newest version with the new bootstrap framework. I didn't realize the old project was using mostly VB until I started the redevelopment in C#. I noticed that the old project is also using some C#. I am trying to see if I can have those two languages inside a new ASP.NET project or not by adding VB files. If not, I'll just make a VB project and convert all of the C# code to it.

When you open the "Add new file" dialog inside a project, it is filtered by the current project type you're working on. E.g. you cannot add a *.vb file to a C# project type, without hacking it somehow.
The GUID within the *.csproj file defines the current project type. This site contains a set of known GUIDs, it is somewhat outdated since it's from 2008.
As I said in a comment, the reason you have been able to mix-in both VB and C# code within the web project, is by using CodeFile attribute, rather than the CodeBehind attribute. The latter will compile all the source files within the project into an assembly with the same name. This will be the file you are uplading to your webserver along with the .aspx files.
Sample file structure:
bin/MyApp.MyProject.dll
Index.aspx
The CodeFile variant, which compiles the source on the fly will need all the files in the same directory, or in the directory specified within the attribute, for this example it will reside within the same directory. This will also allow you to change the code at the web server, and not having to download the code to your development environment. (This is NOT recommended, as you wave goodbye to any version control and other useful tools.)
Sample file structure:
Index.aspx
Index.aspx.cs
My advice would be to decide whether or not to continue developing in VB, or switch to C#. Containing your codebase to one language is preferrable. And if you decide to refactor the whole solution, why not give ASP.NET MVC a go? :-)

Actually there used to be, not sure if it's still available, to put a VB file in a C# project. You would have needed to add a text file type but name it with a .vb extension. Then place it in a folder. Then in the app or web config, you needed to add some config to tell the runtime where to find the vb files and to use VB compiler to compile the code.
It worked but was clunky and not recommended. Again, not sure if it's available anymore.
Personally, if you have VB code, use a vb2cs converter like this one to begin converting it over. They are not perfect but it's at least a good start in most cases.

Add ascx.cs file to production web application

One of our clients has installed our web application into production.
We need to do a very quick patch to one of the aspx controls. I tried dropping the ascx and ascx.cs source files into the dir and unsurprisingly I got this error:
Exception type - HttpParseException - The base class includes the field 'foobar', but its type (UserControls_Controls_FOO) is not compatible with the type of control (ASP.usercontrols_controls_foo_ascx).
Yes, this approach is never a good idea, but is there anything I can do to the control to get it to run in the site instead of the version compiled into the DLL?
Doing a fresh install is not an option at this point.

no , you need to get it into compiled DLL and fresh deploy only then you can see the patch working

If you changed only ascx file you must update only it.
But if you updated ascx.cs you must Publish project and replace old bin directory with new one.
Also you can transform site to set of dynamically compiled pages, but it is hardcore old way and bad idea nowadays.

Creating a single CRM plugin DLL to store in the CRM database

Since the suggested way of storing plugins in MS CRM is via the CRM database, I figured it's about time to do something about the method I'm currently using, which is storing the DLLs on the disk.
The trouble however is that I don't know how to embed all the other various bits that are needed by the DLL: the localization resource files (which are kept in another folder) and some referenced DLLs from the latest SDK (which had to be manually placed in the bin\assembly folder). At this point, I'm not even entirely sure this is possible.
So far I've tried to solve the localization problem by changing the build action on the resource files to "Content" or "Resource" and tested this solution (still keeping the location on-disk, but without the added localization folder). This didn't work: when I purposely generated a validation error in one of the plugins, I got the default language message (English) despite having a different language selected in the CRM.
I've faced a similar problem when trying to add some of the referenced DLL files (namely the new SDK DLLs: xrm.portal, xrm.portal.files and xrm.client). When I tried to store the plugin in the database (skipping for a moment the localization issue), I got a CRM error saying it cannot find the XRM.Client assembly or one of it's dependencies. I know I could use ILMerge to put the whole thing together, but I've got a gut feeling telling me this isn't really a good idea.
Any hints or suggestions on this issue would be great.

We always ILMerge our plugins and have had no issues with that. We don't merge in the SDK dlls, because those will already be GACed on the target server.
We don't really do localization inside our plugin dlls, though, so I think what you may have to do is, if your current resource manager is file based, to make it assembly based and just load up the necessary resources from that.

I have a set of helpers that are bundled in an external assembly that I use for most of my implementations. I will deploy this to the bin folder and leave it at that. I've never tried ILMerge myself, but it seems like an interesting concept.

Simply drop the DLLs in the folder CRMWeb\Bin