Compiling VS2005 project for .NET framework 1.0 or 1.1

[Dave Booker]

I need to compile a VS2005 project to run using the 1.1 framework (i.e.,
app.config containing <supportedRuntime version="v1.1.4322" /> ).

(If I just compile and run with such a setting it functions, but I can't
tell which framework it's using.)

Is there any way to specifically compile for 1.1 with the standard Studio,
or do I have to seek recourse with plug-ins like the following?

http://www.gotdotnet.com/codegallery...a-9b8d00970371

[Michael Nemtsev]

Hello Dave,

Have u looked at MSBee tool?

DB> I need to compile a VS2005 project to run using the 1.1 framework
DB> (i.e., app.config containing <supportedRuntime version="v1.1.4322"
DB> /> ).
DB>
DB> (If I just compile and run with such a setting it functions, but I
DB> can't tell which framework it's using.)
DB>
DB> Is there any way to specifically compile for 1.1 with the standard
DB> Studio, or do I have to seek recourse with plug-ins like the
DB> following?
DB>
DB> http://www.gotdotnet.com/codegallery...id=9ac94da5-8e
DB> 5a-4a33-beda-9b8d00970371
DB>
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Dave Booker]

Right, that's the plugin I was referring to. I guess I could try that, I'm
just surprised that I would need third-party software to accomplish this.

"Michael Nemtsev" wrote:

Hello Dave,

Have u looked at MSBee tool?

[Michael Nemtsev]

Hello Dave,

I couldn't open your link.
The reason is that by default each version of VS is directly corresponds
to the specific .NET FW.
Thus there is no other way than using 3rd part tools for your task, it's
rather normal to use it

DB> Right, that's the plugin I was referring to. I guess I could try
DB> that, I'm just surprised that I would need third-party software to
DB> accomplish this.
DB>
DB> "Michael Nemtsev" wrote:
DB>

Hello Dave,

Have u looked at MSBee tool?

---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Jeffrey Tan[MSFT]]

Hi Dave,

Yes, I have tried to use app.config with <supportedRuntime> element to
redirect the assembly compiled with VS2005 to use .Net CLR1.1:
<?xml version ="1.0"?>
<configuration>
<startup>
<supportedRuntime version="v1.1.4322" />
</startup>
</configuration>

I got a "Strong name validation failed" BadImageFormatException dialog
while running this VS2005 exe. I also tried to adding <assemblyBinding> and
<bindingRedirect> elements to the app.config file to redirect the
referenced assembly binding version, but the BadImageFormatException dialog
keeps generating.

I have tried to contact our Dev team regarding this issue. Below is their
feedback:
"You cannot run V2.0 Framework apps on V1.1. There were non-forward
compatible changes. This is the intended behavior, v1.1 Framework will run
on v2.0 but not vice versa."

So it seems that CLR2.0 does not support redirecting the runtime to
Net1.0/1.1 with app.config file.

If you have .Net Framework1.1 installed and your C# source code file is
compatible with .Net1.1, you may use csc.exe in .Net Framework1.1 to
compile your project. This should be the simplest workaround.

Hope the information helps!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Michael Nemtsev]

Hello Jeffrey Tan[MSFT],

No, that's not completly true

..NET FW support backward compatibility but it couldn't be guarantee
Only several asseblies are unified in the scope of different .NET FWs

For unification use version policy like this

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Xml"
publicKeyToken="b77a5c561934e089" />
<bindingRedirect oldVersion="0.0.0.0-2.0.3600"
newVersion="1.1.5000" />
</dependentAssembly>
</assemblyBinding>

You can set such behaviour for each assembly that you can make unify
J> Hi Dave,
J>
J> Yes, I have tried to use app.config with <supportedRuntime> element
J> to
J> redirect the assembly compiled with VS2005 to use .Net CLR1.1:
J> <?xml version ="1.0"?>
J> <configuration>
J> <startup>
J> <supportedRuntime version="v1.1.4322" />
J> </startup>
J> </configuration>
J> I got a "Strong name validation failed" BadImageFormatException
J> dialog while running this VS2005 exe. I also tried to adding
J> <assemblyBinding> and <bindingRedirect> elements to the app.config
J> file to redirect the referenced assembly binding version, but the
J> BadImageFormatException dialog keeps generating.
J>
J> I have tried to contact our Dev team regarding this issue. Below is
J> their
J> feedback:
J> "You cannot run V2.0 Framework apps on V1.1. There were non-forward
J> compatible changes. This is the intended behavior, v1.1 Framework
J> will run
J> on v2.0 but not vice versa."
J> So it seems that CLR2.0 does not support redirecting the runtime to
J> .Net1.0/1.1 with app.config file.
J>
J> If you have .Net Framework1.1 installed and your C# source code file
J> is compatible with .Net1.1, you may use csc.exe in .Net Framework1.1
J> to compile your project. This should be the simplest workaround.
J>
J> Hope the information helps!
J>
J> Best regards,
J> Jeffrey Tan
J> Microsoft Online Community Support
J> ==================================================
J> When responding to posts, please "Reply to Group" via your newsreader
J> so
J> that others may learn and benefit from your issue.
J> ==================================================
J> This posting is provided "AS IS" with no warranties, and confers no
J> rights.
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Jeffrey Tan[MSFT]]

Hi Michael,

As I stated in my reply, I have tried <assemblyBinding> and
<bindingRedirect> elements in the config file to forward the referenced
assembly to .Net1.1 FCL assemblies. However, this is not the key point.

The keypoint is that there is no way to tell OS loader to use CLR1.1
runtime to run our VS2005 compiled assembly. In .Net1.1, we can use
app.config with <supportedRuntime> element to get this done. In .Net2.0,
this will generate BadImageFormatException at loading time.

Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Michael Nemtsev]

Hello Jeffrey Tan[MSFT],

I've missed the point initially. I rekon that OP trying to load .NET 1.*
assembly into .NET 2.0 fw, that's is possible
The reverses is definitly not

J> Hi Michael,
J>
J> As I stated in my reply, I have tried <assemblyBinding> and
J> <bindingRedirect> elements in the config file to forward the
J> referenced assembly to .Net1.1 FCL assemblies. However, this is not
J> the key point.
J>
J> The keypoint is that there is no way to tell OS loader to use CLR1.1
J> runtime to run our VS2005 compiled assembly. In .Net1.1, we can use
J> app.config with <supportedRuntime> element to get this done. In
J> .Net2.0, this will generate BadImageFormatException at loading time.
J>
J> Thanks.
J>
J> Best regards,
J> Jeffrey Tan
J> Microsoft Online Community Support
J> ==================================================
J> When responding to posts, please "Reply to Group" via your newsreader
J> so
J> that others may learn and benefit from your issue.
J> ==================================================
J> This posting is provided "AS IS" with no warranties, and confers no
J> rights.
---
WBR,
Michael Nemtsev :: blog: http://spaces.msn.com/laflour

"At times one remains faithful to a cause only because its opponents do not
cease to be insipid." (c) Friedrich Nietzsche

[Jeffrey Tan[MSFT]]

Hi dbooksta,

I am not sure if you are still monitoring this thread. Below is some more
information regarding MSBee:

From what I understand, MSBee is an add-on to the MSBuild system that
changes the framework targeted. So, you are actually building against the
v1.1 framework using the VS2003 version of the compilers using the VS2005
version of MSBuild (sort of). You can write your code in the IDE but must
use the cmd line to do the building, so it doesn't appear to be a seamless
integration. Maybe in future VS release, we may have the MSBee feature
build-in.

Hope this information helps!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Dave Booker]

Sorry, my notifications must have been misdirected. This is still an open
issue for me, since MSBee is still very buggy and not the most convenient
thing for me since it has to be installed on every computer that wants to
touch the project.

I actually have a paid MS support event open in which this plays a role, and
the engineer seems to think we can force a VS2005 project to run under 1.1
without resorting to MSBee. As soon as he tells me how, I'll follow up!

[Jeffrey Tan[MSFT]]

Hi Dave,

Thanks for your feedback!

You may provide my email(je***@online.microsoft.com(remove "online.")) to
the support engineer, he may contact me for any information he needed.

Also, you may feel free to share any progress here. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[jrett]

I too have been wondering why the build targets are sooo difficult to choose.
It should be able to simply build a .NET 1.1 bin version of the .NET code,
as long as the code is .NET 1.1 compliant.
Similarly, MSBuild should be able to build C/C++ code, or just run a command
line application. The targets should not have to be "Built in" or Patched,
or whatever MSBee does.

--
Jaan
""Jeffrey Tan[MSFT]"" wrote:

Hi Dave,

Thanks for your feedback!

You may provide my email(je***@online.microsoft.com(remove "online.")) to
the support engineer, he may contact me for any information he needed.

Also, you may feel free to share any progress here. Thanks.

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.

[Dave Booker]

Seems like a major oversight.

But just to follow up: I had a support incident escalated all the way to the
VS Development team and the answer on this was there's no native way to
target prior frameworks; MSBee, kludgy though it is, is the best solution for
now.

"jrett" wrote:

I too have been wondering why the build targets are sooo difficult to choose.
It should be able to simply build a .NET 1.1 bin version of the .NET code,
as long as the code is .NET 1.1 compliant.
Similarly, MSBuild should be able to build C/C++ code, or just run a command
line application. The targets should not have to be "Built in" or Patched,
or whatever MSBee does.

--
Jaan

[jrett]

I understand what you are saying, and I'm just now getting my feet wet with
MSBee, which seems to work pretty well, but I just cant figure why they tied
the executing environment so tightly to the build task.

I mean, it shouldn't matter what language, or therefore what version of a
language a build tool was implemented in, it should do it's job regardless of
what language or platform it was implemented on.

In this case, its job is to build software, whether C#/C/C++ or whatever.
It should not matter what the target/task is.

I just don't get the tight coupling.
--
Jaan
"Dave Booker" wrote:

Seems like a major oversight.

But just to follow up: I had a support incident escalated all the way to the
VS Development team and the answer on this was there's no native way to
target prior frameworks; MSBee, kludgy though it is, is the best solution for
now.

"jrett" wrote:

I too have been wondering why the build targets are sooo difficult to choose.
It should be able to simply build a .NET 1.1 bin version of the .NET code,
as long as the code is .NET 1.1 compliant.
Similarly, MSBuild should be able to build C/C++ code, or just run a command
line application. The targets should not have to be "Built in" or Patched,
or whatever MSBee does.

--
Jaan