I have two projects in my solution Bridge and BridgeInterface being used by my applications update process and it's throwing a FileLoadException when I try to run use the Initialize() method from the Bridge class.
The problem is I can't step into this method, and I have run out of ideas, I need to see where the fault lies in the code!
The Bridge projects where not originally originally part of the solution, so I added both the projects and have pointed to their PDB symbol files. (The .DLL's are showing as symbols loaded in the modules window.)
I also have "Just My Code" unchecked and all projects in the solution are targetting the .NET 4 Full Profile.
Checked to see if the implementer was using DebuggerStepperBoundary or DebuggerStepThroughAttribute no such luck.
Any ideas?
Change the assembly references in your main project to use project references.
This way VS can compile the debug versions of the bridge projects and properly keep track of what's going on so you can step into it.
Related
I'm trying to use Blazor WebAssembly hosted by ASP.NET Core. After implementing a page, I saw in Chrome DevTools many of unnecessary dlls are transmitted to client.
There is an example of situation. Let's assume we have following structure of projects in the solution:
BlazorApp.Client (contains Blazor pages)
Reference to BlazorApp.Shared
BlazorApp.Server (contains ASP.NET core)
Reference to BlazorApp.Client
Reference to BlazorApp.Shared
BlazorApp.Shared (contains shared classes)
Reference to ClassLibrary
ClassLibrary (contains some more shared classes)
NuGet reference to AWSSDK.Core
MyEnum.cs (enum, which is used in Blazor page; not using AWS SDK)
So basically BlazorApp.Shared project has reference to some other project, which could have many nuget packages. Minimum code to reproduce the issue is available in repo https://github.com/GTmAster/blazor-treeshake
My assumption is Mono Linker does a tree shaking in Release build, so all unused code and libraries will be excluded from resulting web assembly.
But when I run my app, I see it loads AWSSDK.Core.dll from the server:
Code in BlazorApp.Client doesn't used it, as well as the code in BlazorApp.Server and in BlazorApp.Shared. It is only loaded, because it is referenced in ClassLibrary.
Am I getting the wrong idea about Mono Linker tree shaking?
Is the only way to exclude this dll from shipping is to move MyEnum to BlazorApp.Shared and break BlazorApp.Shared -> ClassLibrary reference?
I've been investigating this too. It seems that the Linker doesn't do what you expect it to.
https://github.com/dotnet/aspnetcore/issues/28546#issuecomment-742100867
By default Blazor (and all of .NET Core) does not trim application code, it only trims the framework. There are patterns of code that are problematic with trimming. The runtime libraries have been updated and tested to make sure they play well with trimming, arbitrary libraries or user code might not be.
Upon further digging, it seems like you'd need to use Trimming to get further reductions in size. But I found this article, which at the bottom states:
The following trimming approach is being taken for Blazor Apps in .NET 5:
Assemblies from the shared framework/runtimepack get member-level
trimming
Microsoft.Extensions.* assemblies get type-level trimming
from TrimMode=Link
Assemblies from Microsoft.AspNetCore.* are trimmed
via hand generated XML file
All other assemblies are not trimmed
All in all means that the Linker / Trimming isn't going to remove unused assemblies as that's not what it does. It essentially just trims stuff out of the Framework assemblies that it believes you do not need.
You are right, the mono linker is tree shaking.
The only relevant information I could find is here: https://devblogs.microsoft.com/aspnet/blazor-webassembly-3-2-0-preview-2-release-now-available/
You may notice with this preview release that the download size of the app during development is now a bit larger, but build times are faster. This is because we no longer run the .NET IL linker during development to remove unused code. In previous Blazor previews we ran the linker on every build, which slowed down development.
So as it is stated:
Now we only run the linker for release builds, which are typically done as part of publishing the app.
Are you looking into release builds?
Try following the this advise if you want tree shaking in debug builds.
If you prefer to still run the .NET IL linker on each build during development, you can turn it on by adding <BlazorWebAssemblyEnableLinking>true</BlazorWebAssemblyEnableLinking> to your project file.
I stumbled into a cooperation project, where the other part references an interface library of mine and deploys a self compiled MEF Plugin for our tool. I know which methods those guys are using and I want to monitor our library during the the build process, if the method signatures have been changed (just to make sure, noone checked in stuff, which should lead to another interface version and impairs the plugins loadability).
Actually, I have a console project in mind, where the signatures are somehow hardcoded and checked via reflection - but maybe there is a more elegant or simple way.
Any hint would be great.
Thanks in advance!
Roslyn 2.3 introduces a feature for generating reference assemblies. That is an assembly containing only public types and members. When used together with the "deterministic" feature (=> reproducible builds), the generated reference assembly remains binary identical as long as no changes to the public interface is made (implementation changes and private/internal members don't matter).
So you can add this to your csproj:
<PropertyGroup>
<Deterministic>true</Deterministic>
<ProduceReferenceAssembly>true</ProduceReferenceAssembly>
</PropertyGroup>
Until VS 2017 15.5 comes out, I suggest adding <CompileUsingReferenceAssemblies>false</CompileUsingReferenceAssemblies> to all consuming projects because the IDE (e.g. "go to definition") has some problems with this feature unless you are using the "new project system" that is used for .NET Core and .NET Standard projects. (The idea would be that projects referencing the project are only rebuilt if the public interface changes - this speeds up incremental build for large solutions when only implementations change).
These changes will create a ref folder in your output. You can then check if the checksum of the assmbly in there matches a known cheksum on each build.
I ended up creating a small console application with a try catch block, using the same interface dll and the same objects as the project partner does - compiled with the last released interface library. During execution it falls into the catch branch if the signatures got invalid (discovered by the normal .NET processes) - then the exitcode is raised with -1.
Doing all this in the post build processes, cathcing the exit code as discribed this article and breaking build automatically.
Not very happy with that solution, but got it working ... Further ideas still wanted :-)
I'm about to start developing a desktop application (WPF) based on a "plugin" architecture, and was going to use MEF (and its DirectoryCatalog) to discover and load plugin assemblies. We're going to be developing many plugins, so it seems sensible to keep them in separate VS solutions rather than bloat the "core" application solution, but having only ever worked on single, standalone solutions, I suspect this is going to make debugging a bit tricky. I'm using VS2013 if that makes a difference.
I'm assuming that I'll still be able to step into a plugin in scenarios where the "core" application calls a method in that plugin? And I'm guessing that once in there, I'll be able to set breakpoints in those source code files that have been "visited"? But what if I want to add a breakpoint to a different source code file - one that hasn't been visited while stepping-through? How can I open that file? In a single solution I could just open it via Solution Explorer, but not (I'm guessing) when it's in a separate assembly.
I'm trying to pre-empt any problems I might have with this multi-solution approach, and wondered if VS had any clever features to simplify some of this stuff. Having separate solutions also means first compiling the plugin solution(s) that I want to test, then compiling and running the "core" application solution. While it's only a couple of extra mouse clicks, are there (again) any VS features that could help here?
This is a common scenario and not tricky at all.
In the project properties of your plug-ins, go to Debug -> Start Action and set Start external program to the executable of your core application.
This way, you only have to compile your core application once (probably using a build script that just builds everything), and debugging a plug-in will start the core application with the debugger attached and you can debug the plug-in (as soon as your core apllication loads the plug-in assembly).
Also keep in mind that you can dettach the debugger from the running application, switch to another instance of Visual Studio with another solution opened, and again attach to your running application. This comes in handy if you e.g. debug your plug-in and want to set or use existing break points in your core application.
As long as Visual Studio is able to find the debugging symbols (the *.pdb files), stepping through the code of e.g. your core application while debugging your plug-in is also no problem.
I see two ways to do this.
The more comfortable option:
1. You can add the external solution to the core solution.
Walkthrough: Adding an existing Visual Studio solution to another solution
By doing this you can organize your solution to reference the code and still keep each plugin solution separate at the same time.
You just reference those plugin solutions from your core solution that you currently want to work on. Also, using this approach you can organize the other solutions just like you would with normal projects and move thembetween virtual solutios folders to your liking until you have the most adequate folder structure.
Quote from the article:
The nice thing about this approach is that not only are all the
projects now in one solution but at any time, you can open the
separate solutions without impacting the "master" solution and vice
versa.
The files in the references solution can be opened and edited just like any other file from your "normal" projects, and of course, you can set breakpoint like in any other code file, too.
This way you can both edityour code and step through it, which I personally find much more convenient than switching and attaching to multiple processes.
2. Add the PDB files.
Put the DLLs with their corresponding PDBs of those plugins you want to debug into a folder and configure your core application to use that folder for the DirectoryCatalog. This enables you to step into the plugin code, but you will not be able to edit them.
#Andrew
Regarding debugging, it shouldn't be an issue as long as you drop the .pdb files with assembly in directory which you are using as DirectoryCatalog.
Regarding building plugin solution before Core- as you have 1 build file for each solution, you should check if you can write msbuild commands in a .bat file to get it executed one after other.
Besides all the above suggestions, another way to debug is to attach your addin solution to the running core process. Attach to Running Processes with the Visual Studio Debugger
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instance for each library and application. After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
Would like to understand why this happens and if something can be done to make this work more smoothly?
Not sure if it's relevant but most of my applications I write in VB.NET and libaries in C# (as I'm in progress of changing everything to C#). I also have C# files from the libraries open in the consumer application VS, as it pops up during debugging. I also reference library dlls in the library project /bin/Debug folder, because I'm making a lot of changes at this point of development.
Warning 1 Namespace or type specified in the Imports 'somelibrary'
doesn't contain any public member or cannot be found. Make sure the
namespace or the type is defined and contains at least one public
member. Make sure the imported element name doesn't use any
aliases. 'local path'
..
Error 72 Unable to load referenced library 'path\somelibrary.dll': The
process cannot access the file because it is being used by another
process.
I'm writing applications and libraries simultaneously, and whenever I update a library it's a bit hard to get it recognized in the consumer application. I have open a separate Visual Studio instances for each library and application.
This is the fundamental source of your problem. Visual Studio does not like it when things outside it's control change. You should have a single solution open with all the relevant projects included in it. Then when something changes, all the projects which depend on that project will automatically be rebuilt. (At least, that's the default.)
After rebuilding a library I get in the consumer applications the warning/error below. I then either have to remove the reference and add it again. Or I have to clean and build the library solution 3-4 times, for such warning/error to disappear in the consumer app VS solution. Why would doing that 4 times make any difference to doing it 1 or 2 times..?
I don't think it has anything to do with how many times you clean and rebuild it, but how long it's been since you last made a change - you have to wait long enough for the VS instance building the dll to release the lock on the file, before the VS instance that is using it is able to access it.
When you build a project you lock up the .DLL file in the project you build it from, because that is the version of the assembly that the library instance of visual studio will use - however you are referencing that very same library in another process hence the reason you are seeing the error.
You have two options, keep having two instances and then close the two instances open them again and it will be fine.
What you are better off doing is adding the project itself you are referencing (and are getting the error for) to your solution. Then instead of referencing YourProject/bin/debug/assembly.dll add a reference to the local project via the Projects tab. This will then keep one process referencing the appropriate assemblies that it needs.
For every project in the solution check the project settings -> Compile tab -> advanced compile options... -> target framework(all configurations), see if they are all (for example) .NET framework 4. having different or the wrong framework might cause the problems you're having right now
I'm getting System.IO.FileNotFoundException: The specified module could not be found when running C# code that calls a C++/CLI assembly which in turn calls a pure C DLL. It happens as soon as an object is instantiated that calls the pure C DLL functions.
BackingStore is pure C.
CPPDemoViewModel is C++/CLI calling BackingStore it has a reference to BackingStore.
I tried the simplest possible case - add a new C# unit test project that just tries to create an object defined in CPPDemoViewModel . I added a reference from the C# project to CPPDemoViewModel .
A C++/CLI test project works fine with just the added ref to CPPDemoViewModel so it's something about going between the languages.
I'm using Visual Studio 2008 SP1 with .Net 3.5 SP1. I'm building on Vista x64 but have been careful to make sure my Platform target is set to x86.
This feels like something stupid and obvious I'm missing but it would be even more stupid of me to waste time trying to solve it in private so I'm out here embarrassing myself!
This is a test for a project porting a huge amount of legacy C code which I'm keeping in a DLL with a ViewModel implemented in C++/CLI.
edit
After checking directories, I can confirm that the BackingStore.dll has not been copied.
I have the standard unique project folders created with a typical multi-project solution.
WPFViewModelInCPP
BackingStore
CPPViewModel
CPPViewModelTestInCS
bin
Debug
Debug
The higher-level Debug appears to be a common folder used by the C and C++/CLI projects, to my surprise.
WPFViewModelInCPP\Debug contains BackingStore.dll, CPPDemoViewModel.dll, CPPViewModelTest.dll and their associated .ilk and .pdb files
WPFViewModelInCPP\CPPViewModelTestInCS\bin\Debug contains CPPDemoViewModel and CPPViewModelTestInCS .dll and .pdb files but not BackingStore. However, manually copying BackingStore into that directory did not fix the error.
CPPDemoViewModel has the property Copy Local set which I assume is responsible for copying its DLL when if is referenced. I can't add a reference from a C# project to a pure C DLL - it just says A Reference to Backing Store could not be added.
I'm not sure if I have just one problem or two.
I can use an old-fashioned copying build step to copy the BackingStore.dll into any given C# project's directories, although I'd hoped the new .net model didn't require that.
DependencyWalker is telling me that the missing file is GPSVC.dll which has been suggested indicates security setting issues. I suspect this is a red herring.
edit2
With a manual copy of BackingStore.dll to be adjacent to the executable, the GUI now works fine. The C# Test Project still has problems which I suspect is due to the runtime environment of a test project but I can live without that for now.
Are the C and C++ DLLs in the same directory as the C# assembly that's executing?
You may have to change your project output settings so that the C# assembly and the other DLLs all end up in the same folder.
I've often used the Dependency Walker in cases like this; it's a sanity check that shows that all the dependencies can actually be found.
Once your app is running, you may also want to try out Process Monitor on the code you are running, to see which DLLs are being referenced, and where they are located.
The answer for the GUI, other than changing output settings, was the addition of a Pre-Build Step
copy $(ProjectDir)..\Debug\BackingStore.* $(TargetDir)
The answer for the Test projects was to add the missing DLL to the Deployment tab of the testrunconfig. You can either do so by directly editing the default LocalTestRun.testrunconfig (appears in Solution under Solution Items) or right-click the Solution and Add a new test run config, which will then appear under the main Test menu.
Thanks for the answers on this SO question on test configurations for leading me to the answer.
The reason why this happens is because you either are loading DLLMAIN from managed code, before the CRT has an opportunity to be initialized. You may not have any managed code, be executed DIRECTLY or INDERECTLY from an effect of DllMain notifications. (See: Expert C++/CLI: .Net for Visual C++ Programmers, chapter 11++).
Or you have no native entrypoint defined wahtsoever, yet you have linked to MSVCRT. The CLR is automatically initialized for you with /clr, this detail causes a lot of confusion and must be taken into account. A mixed mode DLL actually delay loads the CLR through the use of hot-patching all of the managed entry point vtables in your classes.
A number of class initialization issues surround this topic, loader lock and delay loading CLR are a bit trickey sometimes. Try to declare global's static and do not use #pragma managed/unmanaged, isolate your code with /clr per-file.
If you can not isolate your code from the managed code, and are having trouble, (after taking some of these steps), you can also look towards hosting the CLR yourself and perhaps going through the effort of creating a domain manager, that would ensure your fully "in-the-loop" of runtime events and bootstrapping.
This is exactally why, it has nothting todo with your search path, or initialization. Unfortunately the Fusion log viewer does not help that much (which is the usual place to look for .NET CLR assembly binding issues not dependency walker).
Linking statically has nothing todo with this either. You can NOT statically link a C++/CLI application which is mixed mode.
Place your DLLMAIN function into a file by itself.
Ensure that this file does NOT have /CLR set in the build options (file build options)
Make sure your linking with /MD or /MDd, and all your dependencies which you LINK use the exact same CRT.
Evaluate your linker's settings for /DEFAULTLIB and /INCLUDE to identify any possiable reference issues, you can declare a prototype in your code and use /INCLUDE to override default library link resolution.
Good luck, also check that book it's very good.
Make sure the target system has the correct MS Visual C runtime, and that you are not accidentally building the C dll with a debug runtime.
This is an interesting dilemma. I've never heard of a problem loading native .DLLs from C++/CLI after a call into it from C# before. I can only assume the problem is as #Daniel L suggested, and that your .DLL simply isn't in a path the assembly loader can find.
If Daniel's suggestion doesn't work out, I suggest you try statically linking the native C code to the C++/CLI program, if you can. That would certainly solve the problem, as the .DLL would then be entirely absorbed into the C++/CLI .DLL.
Had the same problem switching to 64-bit Vista. Our application was calling Win32 DLLs which was confusing the target build for the application. To resolve it we did the following:
Go to project properties;
Select Build tab;
Change 'Platform target:' option to x86;
Rebuild the application.
When I re-ran the application it worked.