I created a new assembly name for one of my projects and must update my DLL files to reflect that. In Visual Studio I can clean the solution and then rebuild to do this locally. From there I must deploy my solution to a server for testing. When I deploy, the DLL's are not being updated on the server and I cannot figure out what is going on. In my build definition I do have 'Clean Workspace' set to all, so I thought it should update.
The solution is under source control and the DLL files are included in the bin.
I can also copy them manually, but I am not sure how to view the DLL files on the server.
Thanks!
Related
I have a visual studio 2019 solution with a few projects that consist of mostly c# class libraries. This solution is never 'deployed' and is always run locally by anyone who uses it. Part of what we do for one of our test projects to work is put certain dll's we use into our bin/Debug folder. One of these is Newtonsoft.Json.dll for example. We have a specific version of that dll that we're required to use.
This is something that is usually done once, the first time we run a test in that project. This all works fine. However, whenever there is a code change and the project builds, for whatever reason all the files that are in "C:\Program Files\IIS\Microsoft Web Deploy V3" are copied into our projects bin/Debug directory and overwriting any of the same files already there (Newtonsoft.Json.dll being one of them), and it's a different version which then breaks our projects dependency on that version of the dll. It's worth nothing there are also a bunch of random other files/folders in that Web Deploy directory that get copied over that our project does not need to be there.
I've checked all build events, and searched the entire solution to see if we reference that directory at all which we don't. I've tried googling similar issues, but almost all of what I can find is related to how to use Microsoft Web Deploy (which as far as I can tell we're not, and intentionally as I mentioned we don't deploy any of this code).
If anyone has any insight on this, it would be greatly appreciated!
Thanks,
Andy
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
I have a click once deployment project that has been working fine for a long time now. I added some new dll's to a project that is referenced by it. The dll's can't be referenced in references, so I added them as files to the project.
Build Action is Content, copy to output directory is copy always.
when I build the application, the dll's appear in the bin\debug directory. The program uses them just fine too on my computer. When I deploy the application, the dll's don't make it to the other computer.
Under Publish in application properties I went to application files. the dll's I need are not listed there to be included in the deployment.
I would love some help, I feel like I'm missing something really simple.
I have a feeling if I put the dll's in the main project, it would work. I don't really want to do this, I would like to keep them all located in the project they are actually used in.
When I deploy the application, the dll's don't make it to the other computer.
...
Under Publish in application properties I went to application files. the dll's I need are not listed there to be included in the deployment.
You need to set them to download with the application. Click the DLL in the project properties, then press F4. Set the Build Action to Content, and the Copy to Output Directory to something like 'Copy if newer'
For information - it is likely if you download the DLLs for referencing by a built exe (for example) you may need to configure a manifest file for the executable as well to get it to pick up the DLLS correctly
I am working on a project in Visual Studio that is under source control. I changed the Assembly Name and therefore the name of the assembly dll was changed. If I clean the solution and then build it then the DLLs are updated in the bin held locally. I do not have the bin in source control. I am then deploying to a server for testing using MSBuild. Now I am getting an error when I go to the website on the server because it appears that the DLLs on the server are not being updated. When I use MSBuild, I have 'Clean Workspace' set to 'All', which should clean the solution and then build again on the server. But that doesn't appear to be happening. I cannot find where the Bin directory is on the server to check either.
Thanks for your help!
Sometimes when MSBuild or WebDeploy needs to overwrite the old executable/library but fails to because some process is still accessing it, MSBuild doesn't do a lot to let you know.
If you have access to the server go to the directory (usually C:\inetpub\wwwroot\\bin) and try to remove the old files yourself (may require killing a w3m process) and then redeploy.
I have a very huge application, having more than 400 different projets. Most of them have been developped in very small solutions, much of them having only from 2 to 5 projects and all having a project called "Main", which is the startup project that calls the other one, for loading time purposes and efficiency.
I have added all of those 400 projects to my TFS build definition manually.
Now comes 2 questions :
1- It seems in TFS that my projects needs to be placed in the good build order in my build definition? TFS does not automatically detect the dependencies, as my little NAnt was doing all alone??? Do you imagine having to figure out the right build order for a solution containing 400 projects? This would be easy if they would have been in the same solution, but that is not the case.
2- We use third parties assemblies (Dlls). I have added a folder names "CommonDlls" into my TFS workspace. My builds starts correctly and starts compiling my first projects and sending them into the "bin" directory of the build. Perhaps, when the build trys to compile the first project referencing a 3rd party assembly, it cannot find it... Is there a way in pre-build script to copy the files located in the "CommonDlls" folder to the "bin" outdir of the build? Will TFS use those Dlls when compiling each project or it really tryes to use the referecend path into every single project?
Let's say my project on my development machine as "c:\TFS\bin" as a reference path where are located all dlls, will TFS try to look for that folder or it will use the outdir (it's own created bin folder) ?
The most effective way is to package the DLL's logically into NuGet packages. You can then store them on a file share and configure Visual Studio and you build server to fetch the correct ones at build time. This negates the need to burden your source server with big binaries and allows the server to cache the packages between solutions.