Develop Reference

How to Develop a software which has extensions

I want to develop a software which accepts the extension like that of Visual Studio Code. For example Software S has default functions f, then the extension e will help add new feature which will extend the functionality of the software. I searched for tutorials but I was not able to come up with the solution nor a good tutorial. Am I not searching with right tutorial? Please help.

"Copy Local" when set to true ensures that the dll for the assembly reference is added to the referencing project's bin folder so that it's available at the run time. If the required dll is not found in the bin folder then, the one in GAC can be used. If even then, the dll is not found, we will encounter errors.
If the same version of the dll exists in bin as well as GAC then, the one from GAC is used but if a different version is used and referenced in the project then the one from bin gets used. Similar question answered in Dll in both the bin and the gac, which one gets used?

WPF ClickOnce missed references

I have a WPF app that works with local SQLite and Entity Framework Core. I want to distribute my app using ClickOnce.
Everything works fine when I run it using Visual Studio 2017. But app had a crash on a start when I used ClickOnce. The crash was so early so I couldn't even log the exception. After some time I found that in publish folder some dlls were missed. For example System.Runtime. All references are NuGet packages. Then I found that despite of I have a reference to the dlls in my project ClickOnce application files list doesn't contains it.
The only solution I have found for now is to add missed dlls as files in root of my project and set build action to Content. In ClickOnce application file dialog I set publish status to Include.
It works now but it looks like not the best way to do it. The question is why they are missed in the first place. More likely I missed something or I am not understand the root of the problem.
UPD:
You can find an example code here.
It works from Visual Studio but crashes on a start when you try to install it as ClickOnce application.
UPD: The problem was fixed in Visual Studio Professional version 15.6.1

There are two ways solving solve this.
At first, you have to go Properties → Publish → Application Files, and at this place, make your DLL files include in your project
But if it does not work, go to References and make the DLL file CopyLocal = False. You add a DLL file like Existing Item in your project and make them Copy Always.
It will work correctly.
But for your sample I watch this and I solved it. Look at this image:
You have four DLL files. You need do this for them:
System.Diagnostics.Tracing.dll
System.Reflection.dll
System.Runtime.dll
System.Runtime.Extensions.dll
At first go to your reference and make them Copy Local False:
Then go to the path of each DLL file and add them like Existing Item, and then make all of them Copy To Output Directory CopyAlways
Then Publish it and run it like in this picture. I run it from publish file and it works.

Even if you set the dll to copy local, the dll will not get copied over unless you actually use the dll in your code. You might try adding System.Runtime in your code somewhere like this maybe?
var dummytest = System.Runtime.GCSettings.IsServerGC;

Based on Issue 9 on https://blogs.msdn.microsoft.com/bclteam/p/asynctargetingpackkb/ I was able to do the following:
Symptom
ClickOnce applications targeting .NET Framework 4.0 that reference the Microsoft.Bcl or Microsoft.Bcl.Async packages may experience a TypeLoadException or other errors after being installed.
Resolution
This occurs because ClickOnce fails to deploy certain required assemblies. As a workaround, do the following:
Right-click on the project and choose Add Existing Item
Browse to the folder where the System.Runtime.dll lives
In the File name text box paste in the path of the file
Click the down-arrow next to the Add button and choose Add as Link
In Solution Explorer, holding CTRL select System.Runtime.dll
Right-click the selection, choose Properties and change Copy to Output Directory to Copy always
Republish

How to correctly reference a dll in Visual Studio 2010?

I have a solution that contains a C++ DLL project, and a C# project that will use this DLL (by using PInvoke).
The dll is being built to the x64/Release folder in my solution folder, which makes sense, because that way the C# project doesn't have to poke into the DLL project's folders.
I wonder what would be the correct way to reference it now though. Right now, the DLL project is a dependency of the C# project. My intuition told me that that should have been enough, but the C# project says it cannot find the DLL.
Should I just add the .dll file as a reference too? I thought this might work now but break things in the long run when project settings might get changed around.

I've answered a similar question before. So I don't repeat the text here.
You might want to take a look of:
When using open source libraries, should we compile against the source or the binaries?
Wish that helps.

Usually in such situations I configure my solution such that all projects compile to $(SolutionDir)bin\$(Configuration). The binaries are then located the same way as in production mode and DLLs may be easily used.
As for keeping the latest version of DLL, remember, that you may set a dependency, such that if anything changes in DLL, it will be rebuilt prior to building your assembly / application.
Yet another way is to use build events (prebuild and postbuild) to copy your DLL into appropriate folder.

You can not add an unmanaged DLL as reference in a managed project. The DLL needs to reside either in the executable's folder or in any other folder of the system's PATH.
The best way is to use a "Post Build Event" to have VS copy the DLL into the folder where it is needed every time it is rebuilt.

The source file is different from when the module was built error

I currently have one solution that references ten .dll files. Those .dll files in turn all reference a shared .dll file.
Today I started getting an error while debugging that stated, "The source file is different from when the module was built error.", immediately following a recompile of the shared .dll.
I tried all of the usual. I deleted bin and object folders. I recompiled. I closed all instances of Visual Studio and restarted after they were all closed. I restarted my machine. Nothing fixed seemed to fix it.

I'm guessing one of your 10 DLLs references a different copy of the shared DLL, and not the one you compiled.
Since you have all the sources, put all the projects in the same solution, and have the DLLs reference the shared DLL's project. This will solve your problem.

It has happened to me too. Once I fixed it by recompiling project-by-project from ground up (in the same order that VS does).
Another time this didn't help. I can't remember what I did then.
I believe it is a bug in VS.
I notice you are running VS2008. The problem might go away with an upgrade (the supposed bug might have been fixed). VS2010 is also nicer to work with than VS2008 so it could be areason of its own to stay current. Why not download an evaluation VS11 and try it there.
Move all projects to one solution, reference them in a simple and correct way. Compile. Now you have the right DLLs everywhere and can go back to your more diverse solution(s).
You can also try to use MSBuild. It is easy since you already have the projects in VS. Once it is build by MSBuild (which VS uses itself) it should probably compile in VS again.
Finally you can try to build with nAnt. Once it compiles you can probably compile in VS again.
Good luck. I've been there. It sucks.

I suppose you referencing in your project directly to some DLL, and not a project. Which means if you even cleanup and rebuild, the same dll will be used like a reference.
Very often this is a problem, so I suggesting you check your references.

[edit] Assumed this was asp.net, disregard. [/edit]
Have you deleted everything your temporary .NET folders?
Either in:
C:\Windows\Microsoft.NET\Framework[Your Version]\Temporary ASP.NET Files
or
C:\Windows\Microsoft.NET\Framework64[Your Version]\Temporary ASP.NET Files

When comparing last-modified dates of the shared .dll across output folders of all of the solutions with the file that was stored in the output folder of the primary solution, I noticed that they were not the same as the file that I had just built.
This didn't make sense to me, so I simply copied the new files into the output folder. This did NOT solve the problem. On subsequent builds, the old version was again placed into the output folder, immediately causing the error while debugging...
During compilation, an older version was being pulled along with one of the other referenced .dlls. There is obviously some sort of check that is made with the names of files pulled in so that only 1 file is used, but no check is made for latest version number.
I was able to actually solve the problem by creating a reference to the shared .dll from the primary solution. Direct references are obviously (or perhaps hopefully) pulled in before files that are referenced by references (and are already copied into the same output folder as those referenced .dlls), so the latest file was successfully pulled in first.
If clarity is needed, let me know!

I rarely respond to posts since I am generally too busy, but I just spent a ton of time on this same exact problem. I am running VS 2008 in Windows 7. I had set the my Visual Studio to run in XP Compatibility Mode to fix some issues I had with a different project and forgot to reset it to NOT run in compatibility mode.
Once I removed the Run In compatibility MODE (In Windows Explorer on the DevEnv.exe) my problem with the source being out of sync with the debug information went away.
Hopefully this might help someone in the future with the same problem.

Upgraded to .NET 4.0 & getting Could not load file or assembly reference to old version of DLL that was removed

System.IO.FileLoadException: Could not load file or assembly 'FOO, Version=1.0.3975.20137, Culture=neutral, PublicKeyToken=2aec35e026e7fee4' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
File name: 'FOO, Version=1.0.3975.20137
I have a C# program that we constantly update and it gets reinstalled and it seems that since I've upgraded the project from VS2005 to VS2010 and .NET from 2.0 to 4.0 I'm getting this strange error where its trying to reference the old version of the dll from the last install.
When I go to the directory where its installed Prorgam Files(x86)/.... the latest version of the DLL is in there. In the code there are no references to the old DLL. The only way to fix this is to uninstall the program manually and reinstall. After that the program works fine.
I am lost and confused as to why it would want to keep referencing an old DLL version when its not even there. I have tried running fuslogvw.exe but it hasnt yielded any useful information. I also thought it was possibly the setup project to I deleted and recreated one from scratch. I've also done the usual clean solution & rebuilding. I've searched all thru the forums and online but most people seem to have a problem where the old version of their DLL is still in the program directory and the new DLL didnt get installed. My problem is the opposite.

I've had this error appear when the Clean action for some reason forgets to remove all the dlls in my project's bin directory, and I've had to manually delete those dlls. You might want to check that all the relevant dlls are getting removed as part of the update process. I'm guessing that's what happens when the program gets uninstalled, which is why it works then.

I would start with Who deployed the last breaking version.
It's possible that their machine incorrectly references a bad / old version, whether in the GAC or a hangover from a BIN directory. Also, you mention reinstalling "manually".. Does this mean that you have some build server or other deployment automation in place? It's possible the assembly reference is being picked up by it.
Basically, you'll need to track down exactly how the bad app is being deployed to that machine and fix it.