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
Have started using SpecFlow recently for API acceptance tests, all is well on first try, but then I get the error below on consequent builds. Deleting the obj and bin folder from my API project and a rebuild fixes it, but then a build after, and it's back.
Please remember this isn't my SpecFlow tests project, it's the project that is being tested, so really shouldn't have any SpecFlow assemblies referenced?
Any ideas what I need to do to make this work without deleting the obj and bin folders time and time again?
The error I get when trying to load any controller action is:
Many thanks!
Is after a build the TechTalk.SpecFlow.dll in your bin folder?
If not check following:
it is set to CopyLocal=true in the References
Before/After Build events
custom MSBuild stuff in the *.csproj that removes files
And yes, the project that is tested should not contain a reference to Specflow. Are they using some Utils from it? When they have the bindings in this project, they should move them to a separate assembly.
Updating all the Visual Studio Tools and Extensions seemed to have resolved this issue. Maybe there was a problem with the SpecFlow extension and upgrading Visual Studio 2015 to the newer Update (Service Pack?) seems to have stopped this reference error!
Thanks to Andreas for taking the time to help me out!
I have a visual studio 2010 web project that when I publish it in debug mode the application works fine and is the latest build.
However, when I try to click the play button/debug mode (in the same build configuration as what I published in) the assembly version is older than the most current one. As mentioned, this is a asp.net application using a c# class library as a reference (also in the solution) and I am debugging using Visual Studio's built-in web server.
I've tried everything I could think of at first in all different combinations as follows:
Clean solution
Clean each individual project
Build solution
Build each individual project
Rebuild solution
Rebuild each individual project
I tried to use a different browser and cleaned my cache as well.
Has this happened to anyone? How can I correct this issue?
It is most likely not set to build. To test this, try build then debug and see if things work. If so, then it is definitely not set to build.
To solve this, open up the Solution Properties. Go to Configuration Properties >> Configuration. Then run down to the project in question and check the Build checkbox. You will then be able to debug again.
This one bit me when a coworker decided the build of the UI was taking too long for his testing and removed it from the build. After discovering the issue, I had him create a separate solution to test in isolation. Yes, multiple solutions can contain the same project(s).
did you try deleting your bin and obj folders and removing your assemblies from the GAC? I would guess that THIS is the problem.
Don't forget to clean your Temporary ASP.Net (c:\WINDOWS\Microsoft.NET\Framework[version]\Temporary ASP.NET Files) files.
After that, do a rebuild and try.
Also, for local development, if you can, then do not GAC assemblies. GAC them while deploying to integration environment. THis will help speed up development a bit.
I have a Visual Studio solution (C#) which represents the core of our application. We build this and it comprises about 10 or so DLLs with corresponding PDBs.
I have several other VS solutions each of which is used for a customer of ours. These VS solutions use the core DLLs and add their own bits as required. The "core" has the main .exe so we do the following in customer specific solution
Post build step in the a project to copy the EXE/DLLs/PDBs into the $(TargetDir)
Set project debug settings to "Start External Program" pointing to the .exe
This all works, tho seems a bit clumsy.
My questions are:
When running via the customer specific solution, how can I
Have the code for the core project open automatically when I step into it
Be able to open a core file and set a breakpoint
I'm used to Java where you reference the compiled and source jars/directories from the Java IDE and that's pretty much it. How can do the same in visual studio (DLLs and PDBs)?
(I would prefer to avoid the GAC if possible because we sometimes have several local builds of the core around at the same time working on different projects)
Mike, if you open an "higher in stack" solution which references a core solution, you can open the source file of the core solution and put a breakpoint in it, then when you debug the current solution Visual Studio is smart enough to step into and trigger your breakpoint if the .pdb files are available in the bin folder.
TO automatically have the debugging control traverse into the core source files, make sure to refer the core dlls from locally build core solution and make sure that have access to it.
Another way is after having the core dlls refered, just open the CS file in which you want to put a break point and debug.
I got this error today when trying to open a Visual Studio 2008 project in Visual Studio 2005:
The imported project "C:\Microsoft.CSharp.targets" was not found.
Open your csproj file in notepad (or notepad++)
Find the line:
<Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
and change it to
<Import Project="$(MSBuildBinPath)\Microsoft.CSharp.targets" />
This is a global solution, not dependent on particular package or bin.
In my case, I removed Packages folder from my root directory.
Maybe it happens because of your packages are there but compiler is not finding it's reference. so remove older packages first and add new packages.
Steps to Add new packages
First remove, packages folder (it will be near by or one step up to your current project folder).
Then restart the project or solution.
Now, Rebuild solution file.
Project will get new references from nuGet package manager. And your issue will be resolved.
This is not proper solution, but I posted it here because I face same issue.
In my case, I wasn't even able to open my solution in visual studio and didn't get any help with other SO answers.
For me the issue was that the path of the project contained %20 characters, because git added those instead of spaces when the repository was cloned. Another problem might be if the path to a package is too long.
In my case I could not load one out of 5 projects in my solution.
It helped to close Visual Studio and I had to delete Microsoft.Net.Compilers.1.3.2 nuget folder under packages folder.
Afterwards, open your solution again and the project loaded as expected
Just to be sure, close all instances of VS before you delete the folder.
This link on MSDN also helps a lot to understand the reason why it doesn't work. $(MSBuildToolsPath) is the path to Microsoft.Build.Engine v3.5 (inserted automatically in a project file when you create in VS2008). If you try to build your project for .Net 2.0, be sure that you changed this path to $(MSBuildBinPath) which is the path to Microsoft.Build.Engine v2.0.
I used to have this following line in the csproj file:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" />
After deleting this file, it works fine.
If you are to encounter the error that says Microsoft.CSharp.Core.targets not found, these are the steps I took to correct mine:
Open any previous working projects folder and navigate to the link showed in the error, that is Projects/(working project name)/packages/Microsoft.Net.Compilers.1.3.2/tools/ and search for Microsoft.CSharp.Core.targets file.
Copy this file and put it in the non-working project tools folder (that is, navigating to the tools folder in the non-working project as shown above)
Now close your project (if it was open) and reopen it.
It should be working now.
Also, to make sure everything is working properly in your now open Visual Studio Project, Go to Tools > NuGetPackage Manager > Manage NuGet Packages For Solution. Here, you might find an error that says, CodeAnalysis.dll is being used by another application.
Again, go to the tools folder, find the specified file and delete it. Come back to Manage NuGet Packages For Solution. You will find a link that will ask you to Reload, click it and everything gets re-installed.
Your project should be working properly now.
I got this after reinstalling Windows. Visual Studio was installed, and I could see the Silverlight project type in the New Project window, but opening one didn't work. The solution was simple: I had to install the Silverlight Developer runtime and/or the Microsoft Silverlight 4 Tools for Visual Studio. This may seem stupid, but I overlooked it because I thought it should work, as the Silverlight project type was available.
In my case, I opened my .csproj file in notepad and removed the following three lines. Worked like a charm:
<Import Project="..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props" Condition="Exists('..\packages\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.1.0.0\build\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" />
<Import Project="..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.1.0.0\build\Microsoft.Net.Compilers.props')" />
<Import Project="..\packages\Microsoft.Net.Compilers.1.3.2\build\Microsoft.Net.Compilers.props" Condition="Exists('..\packages\Microsoft.Net.Compilers.1.3.2\build\Microsoft.Net.Compilers.props')" />
ok so what if it say this: between the
gt/lt signs
Import
Project="$(MSBuildExtensionsPath)\Microsoft\Silverlight\v3.0\Microsoft.Silverlight.CSharp.targets"
/
how do i fix the targets error?
I also found that import string in a demo project (specifically "Build your own MVVM Framework" by Rob Eisenburg).
If you replace that import with the one suggested by lomaxx VS2010 RTM reports that you need to install this.
For errors with Microsoft.WebApplications.targets, you can:
Install Visual Studio 2010 (or the same version as in development machine) in your TFS server.
Copy the “Microsoft.WebApplication.targets” from development machine file to TFS build machine.
Here's the post.
This error can also occur when opening a Silverlight project that was built in SL 4, while you have SL 5 installed.
Here is an example error message: The imported project "C:\Program Files (x86)\MSBuild\Microsoft\Silverlight\v4.0\Microsoft.Silverlight.CSharp.targets" was not found.
Note the v4.0.
To resolve, edit the project and find:
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
And change it to v5.0.
Then reload project and it will open (unless you do not have SL 5 installed).
For me, the issue was the path.. When cloning the project that had a space in the name. The project folder was named "Sample%20-%205" instead of what it should be: "Sample - 5"
Opening the project was fine, but building failed with
Could not find the file:
/packages/Microsoft.Net.Compilers.1.3.2/tools/Microsoft.CSharp.Core.targets
I deleted the obj folder and then the project loaded as expected.
Sometimes the problem might be with hardcoded VS version in .csproj file. If you have in your csproj something like this:
[...]\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets"
You should check if the number is correct (the reason it's wrong can be the project was created with another version of Visual Studio). If it's wrong, replace it with your current version of build tools OR use the VS variable:
[...]\VisualStudio\v$(VisualStudioVersion)\WebApplications\Microsoft.WebApplication.targets"
I ran into this issue while executing an Ansible playbook so I want to add my 2 cents here. I noticed a warning message about missing Visual Studio 14. Visual Studio version 14 was released in 2015 and the solution to my problem was installing Visual Studio 2015 Professional on the host machine of my Azure DevOps agent.
After trying to restore, closing VS, deleting the failed package, reopening, trying to restore, multiple times I just deleted everything in packages and when I did a restore and it worked perfectly.
it seems now that the nuget packages folder has moved to a machine wide global cache, using VS2022
For me the issue was that the solution was to deep into the documents folder and on windows 10 there is a path character limit which was reached. As soon as I moved the solution folder up couple of folders this fixed the issue.