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?
Related
My application references the Sage50 SDK and I need to support multiple versions of the SDK.
In Visual Studio each version of the SDK has its own project and has the SDK DLL's referenced.
But when I build the solution the DLL's overwrite eachother and only 1 version remains.
I can't rename the DLL's because the SDK loads other DLL's by name and will error out when they are renamed. And they are signed.
How would I go about a situation like this?
Make each project uses a 'strong' reference to those different sage SDK assemblies. That is, make sure it specifies a version, culture, and token etc... Nothing worse than a versionless, sloppy reference.
You will have to output your project DLL's to separate locations. Because the build will copy all dependencies to the output folder.
Because of #2, you will have to dynamically load your assemblies in your application. (i.e. Assembly.load(...))
I am pulling this project from a git repository that depends on Microsoft.SqlServer.Types which should install msvce120.dll and SqlServerSpatial140.dll. But for some reason it does not install them. They appear in the solution explorer as seen on the image. But the files are not there in windows explorer.
The project was cloned from a git repository. As soon as I tried to build the project, VS started downloading the necessary nuget packages, but this files fail to download. The original repository has these files marked as git ignored.
Where am I going wrong here? I could simply copy and paste the dlls from the original repository but I want to understand why they are not being downloaded or installed.
If you installed this package into a project using the <PackageReference> style of packages (typically found in .Net Standard / .Net Core applications), then the files are not added because there is a lack of support for the install / uninstall scripts used for this function.
Specifically, when installing / restoring this package, there is an install.ps1 script that is supposed to be ran which creates the folders and places the dll's you're referencing into these folders. Again, there is no support for this functionality in the <PackageReference> style of packaging.
This is juxtapose to the packaging style that uses Packages.config which DOES have support for install / uninstall scripts.
You can read more about this here: https://github.com/NuGet/Home/issues/6330
I have a web app that uses DLLs from this folder:
C:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0
Lately, my HD crashed and I had to reinstall everything, but I've installed the latest version of Visual Studio.
I have tried installing every MVC version that exists (I now have version 1 to 3 installed and MVC 4 runtime) and still I get no v1.0 folder (only a v2.0).
My guess is that this came with an older version of Visual Studio or that MS has changed something on their MVC 1,2,3 installers and they don't include this package of DLLs.
Does anyone know how can I install all the files that v1.0 folder usually holds?
I have tried installing separate DLLs from it using nuget, but things got worse with mixed DLL versions.
OK. Here is what I have done:
I first installed AspNetMVC3ToolsUpdateVS11Setup.exe from here:
https://www.microsoft.com/en-us/download/details.aspx?id=1491.
This will add the v1.0 folder. This seems to be an old version, but that's the best I could find...
And then an installer called AspNetMVC3.msi, which I think came from here:
https://www.microsoft.com/en-us/download/details.aspx?id=44533
After that, it seemed working OK. :)
I've build 2 modules for DNN and they work great. Both modules depend on a separate project, that is included by a dll file. Both installations include that dll to the bin folder.
Now if one of the modules gets an update with a newer included dll (assembly and file version is increased for every new version), the older will be overridden by the new dll.
But what if that situation is reversed? I install a version with the older dll file, will the newer be overridden by the older version? I read somewhere that this shouldn't happen, but can't find any information about it.
DotNetNuke manages that for you, as long as you include the version number in the Module install manifest (.dnn file), see here for more information: http://www.dotnetnuke.com/Resources/Wiki/Page/AssemblyComponent.aspx
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