change assembly version of Wpf project - dll

I have changed assembly version of wpf project in Assembly Info.cs file but, it doesn't reflect in dll after build,.

Have you tried to clean the solution and then rebuild?

Related

Visual Studio 2017 MSBuild Task Development

With developing an custom MSBuild Task with Visual Studio 2017 RC, I have the following problem: As soon as I add other dependencies than just Microsoft.Build.Utilities.Core (using v15.1.0-preview-000458-02 for .NET Core Support), I cannot load the task into another .csproj MSBuild project as the dependencies are not found.
Is there a way to automatically copy all dependencies to the Debug folder?
Or do I have to publish it every time I want to test it?
Update1:
The problem with publish was something local to my environment and has been fixed.
Update2:
It seems that as soon as I change the TargetFramework from netstandard1.4 to netstandard1.6 it isn't even able to load the task at all. As soon as I use netstandard 1.6 it throws a an exception:
The task could not be loaded from the assembly.
Could not load file or assembly 'System.Runtime, Version=4.1.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies.
Is there a way to automatically copy all dependencies to the Debug folder? Or do
I have to publish it every time I want to test it?
By default and for good reasons, .NET Core and .NET Standard projects do not copy referenced assemblies into the build folder. Instead, they are resolved them from the NuGet cache.
But if you really need it, this behavior can be changed by overriding the default with the CopyLocalLockFileAssemblies setting.
<CopyLocalLockFileAssemblies>true</CopyLocalLockFileAssemblies>
Cref: https://github.com/dotnet/sdk/blob/d20405f91a2959fa91fea6285d9a896286727f2a/src/Tasks/Microsoft.NET.Build.Tasks/build/Microsoft.NET.Sdk.BeforeCommon.targets#L55-L56
Second question
It seems that as soon as I change the TargetFramework from netstandard1.4 to netstandard1.6
To build a task assembly that works on both "MSBuild.exe" and "dotnet.exe msbuild", you should target netstandard1.4 or lower. netstandard1.6 is not compatible with .NET Framework 4.6.1 (which MSBuild.exe runs on.)
If you need API not available in netstandard1.4, you will need to cross-compile your task for .NET Framework and .NET Standard, which is considerably more complex but can be done.

Dotpeek - Modify DLL Files - Use modified(recompiled) in project

I already did the process - Importing dll file in Dotpeek and Exporting Assembly to Project, Now I can modify dll file in VS 2015, but how to recompile the project and use recompiled dll file again in existing project.. I tried with building project in vs 2015 but it displays lots of compile time errors, Please help
Thanks :)
Rather unfortunately, there is no decompiler that will produce code that compiles for an assembly containing more than a couple of classes.
So you might want to try JustDecompile + Reflexil to do your edit. The advantage of this approach is that only the part you edit will get changed and the rest of the assembly will remain the same as original.
You can use dotPeek of Jetbrains, can open any DLL with it by just right-clicking the DLL and Open with dotPeek.
Once DLL is de-compile in dotPeek, right-click click on the DLL in the left sectoin and chose the option Export to Project.
It will open the entire DLL as a Class Library Project in Visual Studio in the case of .NET DLL.
You can modify the source code and recompile the DLLs.
I am not very sure about your requirement, I would advise you to Extend the DLLs method/operation into your project rather than doing an edit on the recompile on the DLL.

TFS and Microsoft.common.targets assembiles out of sync VS2015

I just upgraded my TFS source to use DevExpress 15.2.5. However, now I get a bunch of warnings in the output such as
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3274: The primary reference "C:\Users\User1\Source\Release\V6.1\CommonBin\Release\WebControls.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.5" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".
and
C:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3275: The primary reference "C:\Users\User1\Source\Release\V6.1\CommonBin\Release\WebControls.dll" could not be resolved because it has an indirect dependency on the assembly "DevExpress.Data.v15.2, Version=15.2.5.0, Culture=neutral, PublicKeyToken=7ea533hgx2169hs3" which was built against the ".NETFramework,Version=v4.0,Profile=Client" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v3.5".
along with about 30 other similar warnings.
It's obvious that something is out of sync with my assemblies because they are referencing the wrong versions. So I looked at my TFS project .csproj file. The version of DevExpress and .NET framework that are being referenced in there are correct.
I then went to the Microsoft.Common.targets file and opened in Notepad. I noticed that file is referencing the old version of everything. How do I get this in sync with my TFS assemblies?
It looks like you need to change your project to use the .NET framework version 4.5 on the project properties page:
Word of warning this may result in more warnings or errors depending on the .NET APIs you use.

Script# and WF Xaml files in the same project, can't compile

We have a VS 2010 MVC3 project, targetting .NET 4.0 (machine has .NET 4.5), the project contains a WF Xaml file and related classes. We needed to access jQueryValidation on the serverside, so we added the script# jQueryValidation NuGet package (v 0.7.5.0), we get the following compile error without even using script# yet:
Error 1 XC1020: Build error occurred in the XAML MSBuild task: 'Could not load type 'System.Runtime.CompilerServices.ScriptAssemblyAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'.....
The Xaml file contains references to the standard mscorlib, we've attempted to strong reference the Gac library in Xaml, via version #...however its to no vail. The project will only compile once we remove the Script# libraries. Then in an effort to narrow down the problem, we installed the nuget package for script# 0.7.5.1, not the jQueryValidation package, and we are able to compile. Installing the jqueryvalidation package afterwards will result in the same error as before, could this be related to the package being based on 0.7.5.0?
Any hints? we would really like to use script# jqueryvalidation and WF Xaml in the same project.
Thanks in advance.
Script# assemblies are meant to be used by script# projects only, i.e. those projects that contain c# code to be compiled into javascript. Your MVC project itself is not a script# project. Likely what you should be doing is creating a separate script# project, to generate script that gets deployed into/via your MVC project.
Specifically script# comes with its own mscorlib with script# specific types not present in the desktop mscorlib assembly.

Where is the .NET Framework Global Assembly Cache?

I installed the VS2010 and .NET 4.0, then I compiled an assembly and ran the gacutil using the exe available on
%ProgramFiles%\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
The output of the executable said the assembly was sucessfully installed on Global Assembly Cache. However, when I go to %WINDIR%\assembly folder I cannot find the assembly I installed using the .NET Framework 4.0 gacutil.
I've seen some posts saying the .NET Framework 4.0 has a separated GAC, but what I haven't found was where it is located.
May someone to help me to check where can I see the Global Assembly Cache of .NET Framework, as it used to work on previous version (%WINDIR%\assembly)?
Yes, there are two distinct GACs as from .NET 4.0
See here: .NET 4.0 has a new GAC, why?
As stated below, the new physical location is %windir%\Microsoft.NET\assembly\ (you can interogate it using the dir command at a command prompt if you're interested).
It's worth noting that applications running up to the 2.0 CLR will not even be able to see assemblies in the new GAC.
Try:
%windir%\Microsoft.NET\assembly\
Due to Common Language Runtime (CLR) changes, the contents of the Global Assembly Cache (GAC) is split between two directories:
%WINDIR%\assembly\
%WINDIR%\Microsoft.NET\assembly\
If you run the command gacutil -l from the directory of your project's .csproj file, you will get a printout of the contents of the GAC (the contents of both directories).