Mixing
![how to prove the following inequality by using real analysis [duplicate]](https://lh4.googleusercontent.com/-0zHZKUELfDo/AAAAAAAAAAI/AAAAAAAAAAc/1UsGPxBk3jQ/s72-c/photo.jpg?sz=32)
Why are there System.*.* dlls in my bin release directory?
When building my application which consists of 10 lines of code and has dependency to Zeroconf & Newtonsoft.json, it produces around 104 dlls in my bin release directoy and a lot of them are System.. dlls.
Why? How can I reduce it to 3 dlls? one for my lib, one for zeroconf and one for Newtonsoft.Json.
nuget
After installing .Net 4.7.1
c# visual-studio
asked Nov 22 '18 at 10:07
AlexAlex
32
|
show 7 more comments
When building my application which consists of 10 lines of code and has dependency to Zeroconf & Newtonsoft.json, it produces around 104 dlls in my bin release directoy and a lot of them are System.. dlls.
Why? How can I reduce it to 3 dlls? one for my lib, one for zeroconf and one for Newtonsoft.Json.
nuget
After installing .Net 4.7.1
c# visual-studio
asked Nov 22 '18 at 10:07
AlexAlex
32
in your references set CopyLocal=false. But if they are used and not available in GAC your app will crash.
– Access Denied
Nov 22 '18 at 10:09
I did set copy local to false for all references except Newtonsoft.Json and Zeroconf. Now I have 102 dlls.
– Alex
Nov 22 '18 at 10:12
Remove you obj bin and try building again.
– Access Denied
Nov 22 '18 at 10:18
Now I have 110 dlls.
– Alex
Nov 22 '18 at 10:25
What version of the framework do you use?
– Hans Kesting
Nov 22 '18 at 10:33
|
show 7 more comments
When building my application which consists of 10 lines of code and has dependency to Zeroconf & Newtonsoft.json, it produces around 104 dlls in my bin release directoy and a lot of them are System.. dlls.
Why? How can I reduce it to 3 dlls? one for my lib, one for zeroconf and one for Newtonsoft.Json.
nuget
After installing .Net 4.7.1
c# visual-studio
asked Nov 22 '18 at 10:07
AlexAlex
32
When building my application which consists of 10 lines of code and has dependency to Zeroconf & Newtonsoft.json, it produces around 104 dlls in my bin release directoy and a lot of them are System.. dlls.
Why? How can I reduce it to 3 dlls? one for my lib, one for zeroconf and one for Newtonsoft.Json.
nuget
After installing .Net 4.7.1
c# visual-studio
c# visual-studio
asked Nov 22 '18 at 10:07
AlexAlex
32
asked Nov 22 '18 at 10:07
AlexAlex
32
edited Nov 22 '18 at 11:06
Alex
asked Nov 22 '18 at 10:07
AlexAlex
32
asked Nov 22 '18 at 10:07
AlexAlex
32
asked Nov 22 '18 at 10:07
AlexAlex
32
32
in your references set CopyLocal=false. But if they are used and not available in GAC your app will crash.
– Access Denied
Nov 22 '18 at 10:09
I did set copy local to false for all references except Newtonsoft.Json and Zeroconf. Now I have 102 dlls.
– Alex
Nov 22 '18 at 10:12
Remove you obj bin and try building again.
– Access Denied
Nov 22 '18 at 10:18
Now I have 110 dlls.
– Alex
Nov 22 '18 at 10:25
What version of the framework do you use?
– Hans Kesting
Nov 22 '18 at 10:33
|
show 7 more comments
in your references set CopyLocal=false. But if they are used and not available in GAC your app will crash.
– Access Denied
Nov 22 '18 at 10:09
I did set copy local to false for all references except Newtonsoft.Json and Zeroconf. Now I have 102 dlls.
– Alex
Nov 22 '18 at 10:12
Remove you obj bin and try building again.
– Access Denied
Nov 22 '18 at 10:18
Now I have 110 dlls.
– Alex
Nov 22 '18 at 10:25
What version of the framework do you use?
– Hans Kesting
Nov 22 '18 at 10:33
in your references set CopyLocal=false. But if they are used and not available in GAC your app will crash.
– Access Denied
Nov 22 '18 at 10:09
in your references set CopyLocal=false. But if they are used and not available in GAC your app will crash.
– Access Denied
Nov 22 '18 at 10:09
I did set copy local to false for all references except Newtonsoft.Json and Zeroconf. Now I have 102 dlls.
– Alex
Nov 22 '18 at 10:12
I did set copy local to false for all references except Newtonsoft.Json and Zeroconf. Now I have 102 dlls.
– Alex
Nov 22 '18 at 10:12
Remove you obj bin and try building again.
– Access Denied
Nov 22 '18 at 10:18
Remove you obj bin and try building again.
– Access Denied
Nov 22 '18 at 10:18
Now I have 110 dlls.
– Alex
Nov 22 '18 at 10:25
Now I have 110 dlls.
– Alex
Nov 22 '18 at 10:25
What version of the framework do you use?
– Hans Kesting
Nov 22 '18 at 10:33
What version of the framework do you use?
– Hans Kesting
Nov 22 '18 at 10:33
|
show 7 more comments
2 Answers
2
active
oldest
votes
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2:
"In .NET Framework 4.7.2 we have addresses the known runtime issues
with .NET Standard 2.0. We made changes to the runtime to ensure
that you don’t need additional files deployed along with your .NET Standard library"
So, run Visual Studio 2017 Installer and install .Net Framework 4.7.2 and the Target Pack and target your app as .net 4.7.2.
answered Nov 26 '18 at 15:59
magicandre1981magicandre1981
15.7k34782
add a comment |
The C# IDE has an option for that, "Specific Version = False". Not available in the C++/CLI IDE. Frankly, this is not a real problem. You are probably using the [AssemblyVersion] attribute incorrectly. That version is associated with the publicly visible classes in the assembly. If you make any changes in the public members of those classes then you've got a potentially breaking change that can make code that has a dependency on those classes fail.
At that point should you change the [AssemblyVersion]. And any project that uses the assembly must get their reference assembly updated and must be recompiled.
An otherwise non-breaking change, like a bug fix or a tweak in the non-visible classes produces a new file that is otherwise completely compatible with any project that uses it. You should update the [AssemblyFileVersion] number. Which in a C++/CLI project requires updating the unmanaged Version resource. Changing the corresponding .rc file could be automated, or you could use a #define.
Note how the .NET base assemblies in version 2.0 behaved the same way. Their [AssemblyVersion] stayed at 2.0.0.0 throughout the 3.0, 3.5 and 3.5 SP1 releases. Their file version started at 2.0.50727.42. And got incremented many times over the past 5 years, up to 2.0.50727.4927, give or take.
For the record, that VS2010 bug you linked to is not a bug. It just never worked before, failure was silent. It is a flaw in the C++ build system, mt.exe embeds the manifest after the assembly is strong named. And breaks the strong name in the process because that changes the file hash. VS2010 is actually an improvement, it warns about it rather than silently letting a broken strong name go through. You don't have to delay-sign, only resign with -Ra in a post build event.
answered Nov 22 '18 at 10:29
kemal akoğlukemal akoğlu
15111
add a comment |
Your Answer
StackExchange.ifUsing("editor", function () {
StackExchange.using("externalEditor", function () {
StackExchange.using("snippets", function () {
StackExchange.snippets.init();
});
});
}, "code-snippets");
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "1"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53428460%2fwhy-are-there-system-dlls-in-my-bin-release-directory%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
2 Answers
2
active
oldest
votes
2 Answers
2
active
oldest
votes
active
oldest
votes
active
oldest
votes
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2:
"In .NET Framework 4.7.2 we have addresses the known runtime issues
with .NET Standard 2.0. We made changes to the runtime to ensure
that you don’t need additional files deployed along with your .NET Standard library"
So, run Visual Studio 2017 Installer and install .Net Framework 4.7.2 and the Target Pack and target your app as .net 4.7.2.
answered Nov 26 '18 at 15:59
magicandre1981magicandre1981
15.7k34782
add a comment |
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2:
"In .NET Framework 4.7.2 we have addresses the known runtime issues
with .NET Standard 2.0. We made changes to the runtime to ensure
that you don’t need additional files deployed along with your .NET Standard library"
So, run Visual Studio 2017 Installer and install .Net Framework 4.7.2 and the Target Pack and target your app as .net 4.7.2.
answered Nov 26 '18 at 15:59
magicandre1981magicandre1981
15.7k34782
add a comment |
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2:
"In .NET Framework 4.7.2 we have addresses the known runtime issues
with .NET Standard 2.0. We made changes to the runtime to ensure
that you don’t need additional files deployed along with your .NET Standard library"
So, run Visual Studio 2017 Installer and install .Net Framework 4.7.2 and the Target Pack and target your app as .net 4.7.2.
answered Nov 26 '18 at 15:59
magicandre1981magicandre1981
15.7k34782
This is a .net standard 2.0/net 4.6/4.7.1 issue which was improved in 4.7.2:
"In .NET Framework 4.7.2 we have addresses the known runtime issues
with .NET Standard 2.0. We made changes to the runtime to ensure
that you don’t need additional files deployed along with your .NET Standard library"
So, run Visual Studio 2017 Installer and install .Net Framework 4.7.2 and the Target Pack and target your app as .net 4.7.2.
answered Nov 26 '18 at 15:59
magicandre1981magicandre1981
15.7k34782
answered Nov 26 '18 at 15:59
magicandre1981magicandre1981
15.7k34782
answered Nov 26 '18 at 15:59
magicandre1981magicandre1981
15.7k34782
answered Nov 26 '18 at 15:59
magicandre1981magicandre1981
15.7k34782
15.7k34782
add a comment |
add a comment |
The C# IDE has an option for that, "Specific Version = False". Not available in the C++/CLI IDE. Frankly, this is not a real problem. You are probably using the [AssemblyVersion] attribute incorrectly. That version is associated with the publicly visible classes in the assembly. If you make any changes in the public members of those classes then you've got a potentially breaking change that can make code that has a dependency on those classes fail.
At that point should you change the [AssemblyVersion]. And any project that uses the assembly must get their reference assembly updated and must be recompiled.
An otherwise non-breaking change, like a bug fix or a tweak in the non-visible classes produces a new file that is otherwise completely compatible with any project that uses it. You should update the [AssemblyFileVersion] number. Which in a C++/CLI project requires updating the unmanaged Version resource. Changing the corresponding .rc file could be automated, or you could use a #define.
Note how the .NET base assemblies in version 2.0 behaved the same way. Their [AssemblyVersion] stayed at 2.0.0.0 throughout the 3.0, 3.5 and 3.5 SP1 releases. Their file version started at 2.0.50727.42. And got incremented many times over the past 5 years, up to 2.0.50727.4927, give or take.
For the record, that VS2010 bug you linked to is not a bug. It just never worked before, failure was silent. It is a flaw in the C++ build system, mt.exe embeds the manifest after the assembly is strong named. And breaks the strong name in the process because that changes the file hash. VS2010 is actually an improvement, it warns about it rather than silently letting a broken strong name go through. You don't have to delay-sign, only resign with -Ra in a post build event.
answered Nov 22 '18 at 10:29
kemal akoğlukemal akoğlu
15111
add a comment |
The C# IDE has an option for that, "Specific Version = False". Not available in the C++/CLI IDE. Frankly, this is not a real problem. You are probably using the [AssemblyVersion] attribute incorrectly. That version is associated with the publicly visible classes in the assembly. If you make any changes in the public members of those classes then you've got a potentially breaking change that can make code that has a dependency on those classes fail.
At that point should you change the [AssemblyVersion]. And any project that uses the assembly must get their reference assembly updated and must be recompiled.
An otherwise non-breaking change, like a bug fix or a tweak in the non-visible classes produces a new file that is otherwise completely compatible with any project that uses it. You should update the [AssemblyFileVersion] number. Which in a C++/CLI project requires updating the unmanaged Version resource. Changing the corresponding .rc file could be automated, or you could use a #define.
Note how the .NET base assemblies in version 2.0 behaved the same way. Their [AssemblyVersion] stayed at 2.0.0.0 throughout the 3.0, 3.5 and 3.5 SP1 releases. Their file version started at 2.0.50727.42. And got incremented many times over the past 5 years, up to 2.0.50727.4927, give or take.
For the record, that VS2010 bug you linked to is not a bug. It just never worked before, failure was silent. It is a flaw in the C++ build system, mt.exe embeds the manifest after the assembly is strong named. And breaks the strong name in the process because that changes the file hash. VS2010 is actually an improvement, it warns about it rather than silently letting a broken strong name go through. You don't have to delay-sign, only resign with -Ra in a post build event.
answered Nov 22 '18 at 10:29
kemal akoğlukemal akoğlu
15111
add a comment |
The C# IDE has an option for that, "Specific Version = False". Not available in the C++/CLI IDE. Frankly, this is not a real problem. You are probably using the [AssemblyVersion] attribute incorrectly. That version is associated with the publicly visible classes in the assembly. If you make any changes in the public members of those classes then you've got a potentially breaking change that can make code that has a dependency on those classes fail.
At that point should you change the [AssemblyVersion]. And any project that uses the assembly must get their reference assembly updated and must be recompiled.
An otherwise non-breaking change, like a bug fix or a tweak in the non-visible classes produces a new file that is otherwise completely compatible with any project that uses it. You should update the [AssemblyFileVersion] number. Which in a C++/CLI project requires updating the unmanaged Version resource. Changing the corresponding .rc file could be automated, or you could use a #define.
Note how the .NET base assemblies in version 2.0 behaved the same way. Their [AssemblyVersion] stayed at 2.0.0.0 throughout the 3.0, 3.5 and 3.5 SP1 releases. Their file version started at 2.0.50727.42. And got incremented many times over the past 5 years, up to 2.0.50727.4927, give or take.
For the record, that VS2010 bug you linked to is not a bug. It just never worked before, failure was silent. It is a flaw in the C++ build system, mt.exe embeds the manifest after the assembly is strong named. And breaks the strong name in the process because that changes the file hash. VS2010 is actually an improvement, it warns about it rather than silently letting a broken strong name go through. You don't have to delay-sign, only resign with -Ra in a post build event.
answered Nov 22 '18 at 10:29
kemal akoğlukemal akoğlu
15111
The C# IDE has an option for that, "Specific Version = False". Not available in the C++/CLI IDE. Frankly, this is not a real problem. You are probably using the [AssemblyVersion] attribute incorrectly. That version is associated with the publicly visible classes in the assembly. If you make any changes in the public members of those classes then you've got a potentially breaking change that can make code that has a dependency on those classes fail.
At that point should you change the [AssemblyVersion]. And any project that uses the assembly must get their reference assembly updated and must be recompiled.
An otherwise non-breaking change, like a bug fix or a tweak in the non-visible classes produces a new file that is otherwise completely compatible with any project that uses it. You should update the [AssemblyFileVersion] number. Which in a C++/CLI project requires updating the unmanaged Version resource. Changing the corresponding .rc file could be automated, or you could use a #define.
Note how the .NET base assemblies in version 2.0 behaved the same way. Their [AssemblyVersion] stayed at 2.0.0.0 throughout the 3.0, 3.5 and 3.5 SP1 releases. Their file version started at 2.0.50727.42. And got incremented many times over the past 5 years, up to 2.0.50727.4927, give or take.
For the record, that VS2010 bug you linked to is not a bug. It just never worked before, failure was silent. It is a flaw in the C++ build system, mt.exe embeds the manifest after the assembly is strong named. And breaks the strong name in the process because that changes the file hash. VS2010 is actually an improvement, it warns about it rather than silently letting a broken strong name go through. You don't have to delay-sign, only resign with -Ra in a post build event.
answered Nov 22 '18 at 10:29
kemal akoğlukemal akoğlu
15111
answered Nov 22 '18 at 10:29
kemal akoğlukemal akoğlu
15111
answered Nov 22 '18 at 10:29
kemal akoğlukemal akoğlu
15111
answered Nov 22 '18 at 10:29
kemal akoğlukemal akoğlu
15111
15111
add a comment |
add a comment |
Thanks for contributing an answer to Stack Overflow!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fstackoverflow.com%2fquestions%2f53428460%2fwhy-are-there-system-dlls-in-my-bin-release-directory%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
in your references set CopyLocal=false. But if they are used and not available in GAC your app will crash.
– Access Denied
Nov 22 '18 at 10:09
I did set copy local to false for all references except Newtonsoft.Json and Zeroconf. Now I have 102 dlls.
– Alex
Nov 22 '18 at 10:12
Remove you obj bin and try building again.
– Access Denied
Nov 22 '18 at 10:18
Now I have 110 dlls.
– Alex
Nov 22 '18 at 10:25
What version of the framework do you use?
– Hans Kesting
Nov 22 '18 at 10:33