I am trying to make an (web for IIS) installer package with install shield limited edition. I added the project primary output and content files and debug symbols to the installer, the setup is built, it is installed correctly but now the problem:
Two of the main project referenced projects dlls are not properly built, meaning that an old version of that dll is built and copied in the setup. My (installed) website doesn't work with those because i changed that projects before making the installer.
If i copy the that dll's from the project manually into the installed folder it works.. . My question is : Where does Installshield get those dlls when building the setup? it shouldn't build the project again and add the new(just built) referenced dlls?
Also if i delete my temporary files from Microsoft.net folder in windows it builds correctly the setup(meaning that the dll's are built at that time). On the setup project at 'dependencies' i have marked all the projects i am using for the main project..
I am using VS 2012 and IShield limited edition 2012.
I've been including DLLs in my main project's bin\release folder in the installshield 2012 LE projects by adding them to the [INSTALLDIR] in the 'Files' section. HTH
I had the same issue today. My .NET project had a DLL inside it that the project referenced. InstallShield was building the MSI with an old version of that DLL.
Clearing the Temporary ASP.NET Files folders resolved the issue. Wasn't able to diagnose why InstallShield has this issue.
Here are the paths specifically that I cleared:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files
Related
We re working with GIT. We have a problem with control with the versions of DLL files. Sometimes one person work on dll version 12.0.0, and he want to install new version of this file into only to 8 projects (we have 10 projects inside one solution). After this he pushing new files int repo. Our compilator man when he pulling from repo and compiling the files, has older DLLs version (example 12.0.0 not the newer installed). Our exe file require newer version than 12.0.0, but inside directory we have 12.0.0 version.
How can we control this inside visual studio or inside another application?
I create a new C# project WPF Application - A project for a .NET Core WPF Application.
Framework: .NET Core 3.1.
Project loaded. (you have an empty form)
Right click on your project and check that you have "Output type" Windows application. (It means when you click on build it creates an EXE file in BIN folder of your project)
Then add a new project to the solution : Setup Wizard by extension Microsoft Visual Studio Installer Projects. Then follow steps as is here -> https://stackoverflow.com/a/6090929/15917420
In the end it packages DLL into installator file instead EXE.
So if you take setup.exe and install it, it installs DLL.
Do you have same problem or am I missing something?
If I create WPF with .NET Framework I dont have this problem.
Thank you
EDIT: recorded video: https://drive.google.com/file/d/11ElC0F62klxQOI-beOn6LhcZbyOb7QDT/view?usp=sharing
I had the same issue. Microsoft has published this:
https://learn.microsoft.com/en-us/visualstudio/deployment/installer-projects-net-core?view=vs-2019
Basically is says that for .NET Core projects, you have to use the "published items" instead of "primary output" when building the setup project. It also has a couple of other hints too.
When targetting .NET Core, the "main" project (the one that is the application) gets two files, a dll and an exe file. The exe file is only a stub loader that locates the dotnet runtime and transfers control to the corresponding dll. Simply put, the exe of a .NET core project is executing the dotnet <dll-with-the-same-name>-command.
With this in mind, you need to make sure that your installer installs both the dll and the exe (and any other similarly named files, such as <Application>.deps.json).
I have created a new web site using Visual Studio 2017. The target framework for this site is NetCoreApp 1.1. As this is an MVC project, it references a number of Microsoft and third-party dlls from Nuget. I also have a data project that I created as a library. It is Netstandard1.6. When I build the solution, none of the dlls from the Nuget packages are copied to the bin folder. This causes the app to crash with a FileNotFound exception when attempting to debug it. The project references are being copied correctly, so it appears to only be a problem with Nuget packages. As a workaround, I can publish the project and copy that output to the bin folder, but I shouldn't have to do that, should I?
.NET Core uses the generated .deps.json file in the output to resolve assemblies, so it avoids copying the files unnecessarily during the build.
However if some assemblies try to look for other assemblies in the output directory or the files referenced in the deps.json file cannot be accessed (e.g. testing build output in IIS), you can add this to a <PropertyGroup> element in your csproj file to cause the NuGet assemblies to be copied to the output directory:
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
This 'CopyLocalLockFileAssemblies' doesn't do anything on my end. The only way I found to get the content of the 'runtime' folder in my output is to use 'Publish'. This is not a solution to locally debug an application.
Edit :
Adding the Runtime IDentifiers to the project file seems to do it for me.
Also, .NET Core 3.0 fixes the issue but it is only in Preview.
Edit: After submitting this post I identified the real issue: MSBuild/TFSBuild does not deploy .dll 'CopyLocal=true' files if they are found in the GAC. In this case the "System.net.http.formatting" dll is in the GAC on the build server. Look here and here
After an upgrade from TFS 2012 to 2015, the build agent no longer copies the following DLLs to the drop locations. How can I identify why the build agent is not copying those files?
system.net.http.formatting, System.Web.Http.dll or System.Web.Http.WebHost.dll
Detail
We have solution with MVC projects that reference the above dlls.
The .csproj files use a hint path to reference the files in the solution /packages/... directory. I have confirmed the path is a valid: the solution has a packages directory.
Before the upgrade to TFS 2015, when building the solution, the above files are copied to the drop location. However they are not after the upgrade.
The build does not fail, however after the TFS 2015 update the target web server throws a 'file not found' error. (MVC is not and cannot be installed on the target web server)
The build utilizes a 2012 XAML Build Definition
Looking at the build log files, both reference the .dll files
CSC.exe ...
/reference:D:\B\15...\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll
The build logs shows that only the version build by TFS 2012 copies the .dll file to the drop location. The 2015 build log does not have a line similar to the following:
Copying file from "D:..\packages\Microsoft.AspNet.WebApi.Client.4.0.20710.0\lib\net40\System.Net.Http.Formatting.dll" to "D:..\BIN\EG.WS.EZScan.Web.Intranet\System.Net.Http.Formatting.dll
The build server was not changed during the upgrade other than the re-install of the build agent. The server was not rebuilt. No components were removed or added.
The project did not update to a newer version of MVC. The projects reference version 4.0.0.0. The GACed files on the build server is version 4.0.0.0 (file version 4.0.20710.0)
What else should I look at.
Since you have upgraded to TFS 2015, it's suggested to use the new build system which is completely different from XAML build. Check: https://www.visualstudio.com/en-us/docs/build/overview
It seems you are still checking in the referenced dlls to TFS, which is not suggested. Instead, we suggest restore the packages via a package manager such as NuGet. Check "Migrating to automatic restore" at website https://docs.nuget.org/ndocs/consume-packages/package-restore#msbuild-integrated-restore
If you start to use new build system, you can simply include the Restore NuGet Packages task in the definition before any build task. Detailed information of Nuget Package Restore, please check https://docs.nuget.org/ndocs/consume-packages/package-restore
I'm trying to build my solution using TeamCity / MSBuild.
It's a WebAPI project which shares some entities in a PCL with a mobile client.
I see there are a few caveats around getting the PCL reference libraries installed on a buildserver, which I think I've sorted
(Building Portable Class Library Project in build server fails)
However, I'm getting an error during the build of the portable class library as follows:
[11:20:49][Doctrina.Pcl.Entities\Doctrina.Pcl.Entities.csproj] _GetSdkToolPaths
[11:20:49][_GetSdkToolPaths] GetSdkPropertyValue
*[11:20:49][GetSdkPropertyValue] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\AppxPackage\Microsoft.AppXPackage.Targets(975, 5): error APPX3212: SDK root folder for 'Portable 7.0' cannot be located. See http://go.microsoft.com/fwlink/?prd=12560&pver=1.0&plcid=0x409&ar=MSDN&sar=PlatformMultiTargeting&o1=Portable&o2=7.0 for more information.*
The "help" link doesn't go anywhere useful and it seems to be very google-resistant in terms of finding any resolution.
I don't have Visual Studio 2015 installed on the build-server at all, but I have installed PortableClassLibrary tools, copied the reference directory from my local PC over, etc, as per the other related SO question.
Help please?
I encountered this error when attempting to build portable projects targeting .NET Standard.
I managed to resolve it without installing Visual Studio on my build server, by copying from a machine that does have Visual Studio installed:
C:\Program Files (x86)\Microsoft SDKs\Portable\v14.0
C:\Program Files (x86)\MSBuild\Microsoft\Portable
C:\Program Files (x86)\ReferenceAssemblies\Microsoft\Framework.NETPortable
I later attempted to build a WebApi project targeting .NET Core (this was an xproj file) and as soon as I added the XProj file to my solution, I had to also copy:
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet
C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\DotNet.Web
That got me a bit further but it also caused other projects to stop building properly (that were working fine without the XProj file in the solution). One thing I noticed, the NuGet tooling for .NET Core does not support authenticated NuGet feeds, so I had to enable anonymous access on my feed. But now my .NET Standard project now fails with error MSB4057: The target "_GenerateDependencyFragmentJson" does not exist in the project.
I've yet to get around to diagnosing this, but I hope the above information helps someone. If you're not using xproj files and just trying to use .NET Standard projects, the above should be all you need to build without installing Visual Studio.
Just a side note, I tried really hard to avoid having to copy these files by first trying to install Microsoft Build Tools 2015 Update 3, hoping it would put the required files in place, but it did not sadly. I'm pinning my hopes on the next version of MSBuild that is being used in VS15, and hoping that it's build tools package will have everything required to build this stuff when it comes out, as it doesn't seem like they are updating the 2015 Build Tools with this support.