QGIS » QGIS Application

I don't think it is the same issue - but yes it could be fixed at the same time.
I saw that issue - about corrupted files wich is as they suggest due to the extraneous headers that AutoCAD doesn't like. This is commonly a problem with AutoCad and dxf, I worked with a specialty programme which had the same problem 15 years ago. It could always be fixed by simply deleting the extra header data from the dxf file.
I have other (current) specialty software that can read the dxf that is written by QGIS, and the elevation data is not included. If you look into the dxf file (it is plain text) you can see that the entity dotted pair for the LWPOLYLINEs does not include the "38 pair" which specifies the z value.
Actually this issue would be very easy to rectify by sombody who know the QGIS code (I don't)- simply write the elevation field (say EL = xxx) as 38 xxx into the entity string for each polyline.

Can anyone get rid of the feedback tag?
This issue is still around, but #4381 isn't.

Sorry, actually I don't know if this issue is still around - My shape file was actually 2D so I had to use ogr2ogr with the -zfield option.

I haven't used the feature lately so I can't confirm if it has been fixed, though I suspect it hasn't. Any elevation contour, regardless of whether it was 2D or 3D must han an elevation value (otherwise it's not an elevation contour) that can be exported to the dxf so this should be easily confirmed by just about anybody. As noted before, you can see the structure of the dxf file in any text editor. Start by searching for the word "LWPOLYLINE".

The current dxf definition for the exported contour looks (in part) like this:
"...
0
LWPOLYLINE
5
20000
8
0
100
AcDbEntity
100
AcDbPolyline
70
0
90
27
10
706986.85
20
7663702.09
10
706956.83
20
7663704.41
...."

You'll note that the structure is "10 x-cord 20 y-cord (repeat)". the value 10 signifies that the following number will be the x-cordinate of a vertex, similarly a value of 20 signifies a y-cordinate. The old 3DPOLYLINE structure used a 30 to signify a z-cordinate. But the new LWPOLYLINE entity, which QGIS is using, (see the 0 value in the string above for the entity type) stores the z-cordinate (ie the elevation) on the 38 value. Hence in the string above, if the elevation was "EL", it should read:
"...
0
LWPOLYLINE
5
20000
8
0
100
AcDbEntity
100
AcDbPolyline
70
0
90
27
38
EL
10
706986.85
20
7663702.09
10
706956.83
20
7663704.41
...."

The posiiton of the 38 value is not particularly sensitive, as long as it comes after the 0 value, and preferably before any of the verticies (ie the 10 & 20 values).
That's all that is required to fix this issue. Hope this helps understand / fix this issue.

Any plan to fix this? Thanks.